[Doc] Clarify file-bundling exception for lake_publish_version_retry_interval_ms

For file_bundling=true tables the sticky publish retry does not skip
already-published partitions: each publish rewrites a whole-partition
carry-forward bundle against the currently-visible index set, so those
partitions are always re-published (and may be delayed by this interval on a
failed re-publish). Document this exception in en/zh/ja.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Srihith Garlapati <srihith.garlapati@gmail.com>

Author: srihithg

docs/en/administration/management/FE_parameters/shared_lake_other.md

@@ -624,7 +624,7 @@ This topic introduces the following types of FE configurations:
 - Type: Long
 - Unit: Milliseconds
 - Is mutable: Yes
-- Description: Minimum interval before a partition that failed to publish its version is retried by PublishVersionDaemon in shared-data (lake) mode. Applies to both the single-transaction and the batch publish paths: on retry, a partition that already published successfully is skipped, and a partition that recently failed is not re-attempted until this interval has elapsed since its last failure. Only failed partitions are affected; a partition that publishes on its first attempt is never delayed.
+- Description: Minimum interval before a partition that failed to publish its version is retried by PublishVersionDaemon in shared-data (lake) mode. Applies to both the single-transaction and the batch publish paths: on retry, a partition that already published successfully is skipped, and a partition that recently failed is not re-attempted until this interval has elapsed since its last failure. Only failed partitions are affected; a partition that publishes on its first attempt is never delayed. Exception: for tables with `file_bundling = true`, already-published partitions are NOT skipped on retry. Each publish rewrites a whole-partition bundle against the currently visible index set, so file-bundling partitions are always re-published to keep that bundle current (and may be delayed by this interval if a re-publish fails). This setting therefore does not eliminate re-publishes for file-bundling tables.
 - Introduced in: v4.1
 
 ### `lake_enable_batch_publish_version`

docs/ja/administration/management/FE_parameters/shared_lake_other.md

@@ -646,7 +646,7 @@ ADMIN SET FRONTEND CONFIG ("key" = "value");
 - タイプ：Long
 - 単位：ミリ秒
 - 変更可能：Yes
-- 説明：共有データ (lake) モードで、PublishVersionDaemon がバージョンの公開に失敗したパーティションを再試行するまでの最小間隔。単一トランザクション公開パスとバッチ公開パスの両方に適用されます。再試行時には、すでに公開に成功したパーティションはスキップされ、最近失敗したパーティションは前回の失敗からこの間隔が経過するまで再試行されません。影響を受けるのは失敗したパーティションのみで、最初の試行で公開に成功したパーティションが遅延することはありません。
+- 説明：共有データ (lake) モードで、PublishVersionDaemon がバージョンの公開に失敗したパーティションを再試行するまでの最小間隔。単一トランザクション公開パスとバッチ公開パスの両方に適用されます。再試行時には、すでに公開に成功したパーティションはスキップされ、最近失敗したパーティションは前回の失敗からこの間隔が経過するまで再試行されません。影響を受けるのは失敗したパーティションのみで、最初の試行で公開に成功したパーティションが遅延することはありません。例外：`file_bundling = true` のテーブルでは、すでに公開に成功したパーティションも再試行時にスキップされません。各公開は現在可視の index セットに対してパーティション全体の bundle を書き直すため、ファイルバンドリング (file bundling) のパーティションは bundle を最新に保つために常に再公開されます (再公開が失敗した場合はこの間隔だけ遅延することがあります)。したがって、この設定はファイルバンドリングテーブルの再公開をなくすものではありません。
 - 導入時期：v4.1
 
 ### `lake_enable_batch_publish_version`

docs/zh/administration/management/FE_parameters/shared_lake_other.md

@@ -633,7 +633,7 @@ ADMIN SET FRONTEND CONFIG ("key" = "value");
 - 类型: Long
 - 单位: 毫秒
 - 是否可变: Yes
-- 描述: 存算分离（lake）模式下，PublishVersionDaemon 重试发布失败分区前的最小间隔。同时适用于单事务发布路径和批量发布路径：重试时会跳过已成功发布的分区，最近失败的分区在距上次失败经过该间隔之前不会被重新尝试。仅影响发布失败的分区；首次尝试即成功发布的分区不会被延迟。
+- 描述: 存算分离（lake）模式下，PublishVersionDaemon 重试发布失败分区前的最小间隔。同时适用于单事务发布路径和批量发布路径：重试时会跳过已成功发布的分区，最近失败的分区在距上次失败经过该间隔之前不会被重新尝试。仅影响发布失败的分区；首次尝试即成功发布的分区不会被延迟。例外：对于 `file_bundling = true` 的表，已成功发布的分区在重试时不会被跳过。每次发布都会针对当前可见的 index 集合重写整个分区的 bundle，因此文件捆绑（file bundling）分区总是会被重新发布以保持 bundle 最新（如果重新发布失败，也可能被该间隔延迟）。因此，对于文件捆绑表，该配置并不会消除重新发布。
 - 引入版本: v4.1
 
 ### `lake_enable_batch_publish_version`