fix(native): dispatch txn commit batch to the owning vshard

[laksamanakeris]

Fixes #193.

Problem

A row committed inside an explicit transaction over the native binary protocol (Begin op → SQL INSERT → Commit op) was durably stored but permanently invisible to PK point lookups and filtered count(*) — full scans saw it, and the same SQL over pgwire was correct.

Root cause (full trace in the issue comment): both transports share run_commit → dispatch_single_shard, which builds the commit tasks (MetaOp::ResolveTxn + MetaOp::TransactionBatch) with the correct vshard_id. The pgwire seam submits them with that vshard_id; the native seam (NativeTxnDp::dispatch_no_wal) sent them through gw.execute(...), which drops task.vshard_id and re-routes from the plan. MetaOp plans have no collection name, so the router's primary_vshard fell back to vShard 0 — the whole commit batch (row write + index maintenance) was applied on vShard 0's core instead of the collection's owning vShard.

Fix

• NativeTxnDp::dispatch_no_wal now always dispatches through the direct write path with task.vshard_id, matching pgwire's dispatch_task_no_wal and native's own pre-gateway fallback branch (which was already correct).
• Guardrail: route_plan rejects ResolveTxn / TransactionBatch plans with an error instead of silently misrouting them to vShard 0, so any future caller that sends a commit meta-op through the gateway fails loudly instead of corrupting placement.

Tests

• New integration test native_txn_commit_visibility.rs: the issue's exact repro (Begin op / INSERT / Commit op over the native wire), asserting the committed row is visible to a PK point lookup and a filtered count(*) on the writing connection and on a fresh connection, with the full scan as control. The test wires the gateway the way production boot does and runs 4 data-plane cores with a collection homed off core 0 — reproducing the bug requires both (the default single-core, gateway-less test harness masks it; verified red before the fix, green after).
• New router unit test commit_meta_ops_are_rejected for the guardrail.
• Full cargo test -p nodedb suite passes (one pre-existing, unrelated failure on main: shuffle_grace_infeasible_budget_is_deterministic_error, fails identically on main @ 48281658).

Notes for reviewers

• Rows already committed through native-protocol transactions on affected multi-core deployments remain mis-homed on vShard 0 after this fix (scan-visible, lookup-invisible). Flagged in the changelog; a repair/re-home tool likely deserves a separate issue.
• The multi-shard commit branch is unaffected: it flushes through the Calvin sequencer, not this seam, and every remaining dispatch_no_wal call site goes through the fixed seam.