Persist coordinator gid in the WAL for crash recovery

[crodas]

Attempt to fix #1175

After a SIGTERM and reboot, prepared 2PC transactions were left orphaned on the shards even with the WAL enabled. Recovery replayed the in-flight transactions but drove COMMIT PREPARED / ROLLBACK PREPARED against a gid that no longer matched what Postgres held, so the statements failed and the monitor retried them forever.

The gid a transaction is prepared with embeds a per-process instance_id, which is a fresh random value on every start unless NODE_ID is set. The WAL only persisted the inner transaction id, so a restarted PgDog reconstructed the gid with a different instance_id prefix and missed the orphan. The gid used at recovery must be byte-identical to the gid used at PREPARE, so it has to come from the WAL, not from live process state.

Store the full coordinator gid in the Begin and Checkpoint records (serde default keeps old segments readable) and thread it through recovery so cleanup resolves each prepared xact with the exact gid it was created with. Live transactions still render the gid from process state, which is correct in the process that created them. An empty stored gid falls back to the previous behavior.

The crash-safety WAL helper now records the full gid too, so the integration spec exercises the real recovery path.

[codecov]

Codecov Report

❌ Patch coverage is 95.12195% with 8 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...src/backend/replication/logical/subscriber/copy.rs	0.00%	6 Missing ⚠️
pgdog/src/backend/replication/logical/error.rs	0.00%	1 Missing ⚠️
...c/frontend/client/query_engine/two_pc/statement.rs	93.33%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!