fix: a mid-stream backfill overwrites newer changes

[hasyimibhar]

This PR fixes backfill_does_not_overwrite_newer_changes.

A table added mid-stream has its backfill staged into its log alongside its CDC, in no useful order. A change streamed before the backfill reached its row was staged ahead of the row's older snapshot copy, and applied in log order the old copy won. A row deleted during the backfill came back. An update leaving a TOASTed column unchanged had no row to resolve that column from.

Such a table's snapshot rows are now applied first, then its changes:

• Marker. register_table_pending creates a second mat_cursor row for the table, <group>#snapshot. It marks, durably, that the table's snapshot rows go first.
• Snapshot rows first. Once the backfill is complete, the materializer folds the log's snapshot rows in bounded steps and commits them together. The table goes from empty to its snapshot at once, never half loaded. Only then does it mark them applied. A crash before that re-applies them, which changes nothing.
• Changes after. The table's changes then apply in log order. Snapshot rows are skipped, and so are changes committed before the first snapshot's LSN, which every snapshot row already reflects. A backfill resumed after a restart takes a newer LSN, which is why the first one counts.
• Completeness check. Snapshot rows wait for the coordinator to report the backfill complete, even if the table is ungated early. Otherwise rows staged later would be skipped as already applied.