canal-json: output the transaction start_ts in the _tidb extension block

Is your feature request related to a problem?

canal-json messages carry no transaction identifier, so it is not possible to determine which rows originated from the same transaction from the message stream alone.

Today the only timestamp available is commitTs, and only inside the _tidb extension block (pkg/sink/codec/canal/canal_json_message.go:127):

  type tidbExtension struct {
        CommitTs           uint64 `json:"commitTs,omitempty"`
        WatermarkTs        uint64 `json:"watermarkTs,omitempty"`
        OnlyHandleKey      bool   `json:"onlyHandleKey,omitempty"`
        ClaimCheckLocation string `json:"claimCheckLocation,omitempty"`
        RowKey             string `json:"rowkey,omitempty"`
  }

commitTs is not a usable transaction key. Under the default 1PC / async-commit settings it is not unique across transactions — in a measurement on TiDB v8.5.5 we observed 78% collisions on a hot single-table workload, where distinct
transactions shared a commit timestamp. It can be made unique as (table, pk, commitTs), but that still does not let a consumer group rows by transaction, which is the actual requirement.

start_ts is the natural key: every row in one transaction shares it.

This has already been recognised for two other protocols:

• #5903 — debezium: output start_ts in the source block of DML messages
• #6143 — simple: output start_ts in JSON DML messages (open)

Describe the feature you'd like

Add startTs to the existing _tidb extension block for DML messages:

  type tidbExtension struct {
        CommitTs           uint64 `json:"commitTs,omitempty"`
        StartTs            uint64 `json:"startTs,omitempty"`   // new
        WatermarkTs        uint64 `json:"watermarkTs,omitempty"`
        ...
  }

Describe alternatives you've considered

No response

Teachability, Documentation, Adoption, Migration Strategy

No response

Start with pkg/sink/codec/canal/canal_json_message.go at the tidbExtension definition around line 127, then trace how the extension block is emitted for DML messages. Add startTs to that block and verify that canal-json DML output includes the transaction start timestamp alongside the existing TiDB fields.