sink: make sink statistics consistent and flush-aware

What did you do?

Run changefeeds with different sink implementations and inspect the sink write-byte, batch-row, execution-error, and affected-row metrics.

What did you expect to see?

• Sink statistics use the same label set across sink implementations.
• ticdc_sink_write_bytes_total reports the original DML event bytes only after data is successfully flushed to the downstream.
• MySQL affected-row statistics are updated only after the transaction commits successfully.
• The statistics package owns its Prometheus collectors and exposes only construction and registration APIs.

What did you see instead?

• Write bytes were derived from encoded or output payload sizes, so values differed by sink and protocol.
• Kafka and Pulsar statistics could be updated before the asynchronous send callback confirmed completion.
• MySQL affected rows could be recorded before commit and therefore include failed transactions.
• The sink type label split statistics for the same changefeed into backend-specific series.
• Statistics-owned collectors were exported from pkg/metrics, allowing callers outside the owning package to access internal metrics directly.