[Bug]: CDC NoFull may skip changes committed immediately after task creation

## Summary

A table-level CDC task created with `NoFull=true` can skip source changes committed immediately after `CREATE CDC` returns, while the task remains `running` with no error. The same behavior is reproducible on the current `main` and on PR #27939; this issue is reported as a pre-existing CDC capture-window gap, not as a regression introduced by #27939.

## Environment

- MatrixOne commit: `9add8e46c19b40a1a6488ba5d2969d0b380e2083` (PR #27939 latest head)
- Control code path: current `main` has the same `NoFull` startup watermark initialization
- Host: MatrixOne test machine `10.222.1.55`
- Deployment: single-process quickstart, MySQL frontend `127.0.0.1:6001`

## Reproduction

1. Create matching source and target tables and the required source PITR.
2. Create a table-level task:

```sql
CREATE CDC life55
'mysql://sys#root:111@127.0.0.1:6001'
'mysql'
'mysql://sys#root:111@127.0.0.1:6001'
'bb27939_55.src:bb27939_55.dst'
{'Level'='table','NoFull'='true','Frequency'='1m'} internal;
```

3. Immediately after `CREATE CDC` returns (within about 1 second), insert 1000 rows using a recursive CTE.
4. Wait longer than one polling interval (75 seconds in the reproduction).
5. Query the target and task metadata.

## Actual result

- Target row count remains `0`.
- Task state remains `running`.
- `err_msg` remains empty.
- The watermark advances/heartbeats, but the 1000 committed rows are not delivered.

The same task synchronizes rows inserted after the pipeline has initialized (the control insert reached the target after the next 1-minute poll), so this is a startup capture window rather than a general replication failure.

## Expected result

For `NoFull=true` (documented as “skip initial snapshot, sync incremental changes only”), changes committed after successful `CREATE CDC` should not be silently omitted. The implementation should either:

1. durably define the incremental start watermark as part of task creation and capture all later commits; or
2. document and expose the actual activation boundary, with a state/acknowledgement that tells clients when writes are safe to rely on.

## Root-cause direction

The asynchronous pipeline currently initializes the no-full watermark from `txnOp.SnapshotTS()` when `addExecPipelineForTable` starts. If a source commit lands after task creation but before that pipeline snapshot is taken, the commit is older than the newly installed watermark and is skipped.

## Related / distinction

- #27863 covers large initial-snapshot batch-slot starvation and is a different path.
- #27939 addresses snapshot scheduling and ownership fencing; it does not introduce this behavior.