Clarify chain table streaming read merge-snapshot and changelog-producer restrictions

Author: juntaozhang

docs/docs/primary-key-table/chain-table.mdx

@@ -130,7 +130,6 @@ Notice that:
 - Chain table is only supported for primary key table, which means you should define `bucket` and `bucket-key` for the table.
 - Chain table should ensure that the schema of each branch is consistent.
 - Deletion vector is not supported for chain table.
-- The `changelog-producer` option must be `none` (default) or `input`; `lookup` and `full-compaction` are not supported for chain tables.
 - The delta branch must use the `DEDUPLICATE` merge engine (default) if you plan
   to use streaming read or lookup join. Other merge engine types are not supported
   on the delta branch for these incremental read paths. Batch read is not affected.
@@ -226,8 +225,8 @@ Chain tables support Flink streaming read. A streaming read job operates in two
 1. **Full load phase**: By default it produces a lightweight result by reading the latest
    snapshot partition (per group) and delta partitions that come after it. Older snapshot
    partitions are excluded. You can enable `chain-table.streaming.merge-snapshot` to perform
-   anchor-based chain merging in Phase 1, allowing cross-branch deletes and updates to be
-   visible in the starting snapshot.
+   anchor-based chain merging in this phase, allowing cross-branch `DELETE` records to be
+   resolved together with the snapshot data.
 2. **Incremental phase**: Continuously reads new commits from the delta branch as they arrive.
 
 ### Write-Side Requirements
@@ -254,32 +253,27 @@ SET 'execution.runtime-mode' = 'streaming';
 INSERT INTO downstream_sink SELECT * FROM default.t;
 ```
 
-### Merge Snapshot in Starting Phase
+### Merge Snapshot in Full Load Phase
 
-By default, the full load phase is lightweight: for each group it reads the latest
-snapshot partition and later delta partitions as separate splits. Anchor-based chain
-merging is skipped to keep Phase 1 fast and avoid split explosion in jobs with many
-partitions.
+By default, the full-load phase is lightweight: for each group it reads the latest snapshot and later
+delta partitions as separate splits. This is fast but cross-branch deletes are invisible — the `DELETE`
+records in the delta branch cannot be deleted in the snapshot branch.
 
-If the delta branch contains deletes or updates that must be merged with the latest
-snapshot anchor — for example, a later delta partition deletes a key that exists in the
-latest snapshot partition — you can enable the merge mode:
+If you need a fully reconciled starting snapshot, enable merge mode:
 
 ```sql
 ALTER TABLE default.t SET (
   'chain-table.streaming.merge-snapshot' = 'true'
 );
 ```
 
-When enabled, the starting phase merges the latest snapshot partition per group with
-delta partitions whose chain key is strictly greater than the snapshot chain key. This
-produces a correct starting snapshot that reflects cross-branch deletes and updates,
-at the cost of a heavier Phase 1.
+With merge mode enabled, the full-load phase merges the latest snapshot partition per group with
+delta partitions whose chain key is strictly greater than the snapshot's, so cross-branch
+deletes are correctly resolved. The trade-off is a heavier startup scan.
+
+To reduce the overhead, run `CALL sys.compact_chain_table(...)` periodically.
+After compaction, only the delta changes that arrived after compaction need to be merged.
 
-To reduce this overhead, you can periodically run `compact_chain_table` to merge delta
-partitions into the snapshot branch. After compaction, the snapshot branch contains the
-merged state, so the streaming starting phase can read snapshot partitions directly
-without expensive cross-branch merging.
 
 ### Limitations
 
@@ -298,6 +292,12 @@ without expensive cross-branch merging.
   specific partition, use batch mode instead.
 - The delta branch must use the `DEDUPLICATE` merge engine (default). Other merge engine
   types are not supported.
+- The `changelog-producer` option must be `none` (default) or `input`; `lookup` and `full-compaction`
+  are not supported for chain tables.
+  - When `changelog-producer` is `none`, Flink's operator normalizes records by the full
+    primary key including the chain partition. The records of `-D`/`-U` in a different chain partition
+    than the original records of `+I` will be dropped. Use `input` if downstream must receive cross-partition
+    changelog records.
 
 ## Lookup Join