fix(account): server reads prev commitment pubkey from its own state

[TaprootFreak]

Summary

07-send.spec.ts::send-success still fails on DEV after PR #129 deployed: Interner Fehler: Vorheriger Public Key fehlt. (server prev_commitment_pubkey required for account update, 400). The wallet's local BIP-32 child-index counter (numPubkeys) cannot be kept in sync with the server's persisted state across all the edge cases (seed restore, stale-app deploy, TOCTOU between balance fetch and request signing) — every desync surfaces as a 400.

Direct evidence — the failing send body captured live on dfxdev (request_log id 8132):

{
  \"account_address\": \"75bf7aa9…b2a8\",
  \"recipient\":       \"05c6…b438\",
  \"amount\": 1000,
  \"public_key\":      \"03d29d65…74c1\",       // pubkey at index 0 — alice's FIRST send used this
  \"next_public_key\": \"03cb5c61…360b\",
  \"signature\":       \"2dea93c1…\",
  \"timestamp\":       1779952953
  // ← no \`prev_commitment_pubkey\` field
}

Alice's server-side state was proof=Some, num_sends=1, balance=99000 — and the /api/balance call 0.65s earlier did return num_sends: 1. So either the wallet code did not consume the field, or it consumed it and still derived the wrong index. The deployed zk-coins/app:beta container is from 2026-05-25 — three days before PR #129 — and predates the app-side fix.

Fix

Move the lookup to where the data lives: the server stores
Account::commitment_public_key: Option<PublicKey> and the AccountUpdate branch of send_coins_inner reads it from there instead of from the caller-supplied prev_commitment_pubkey.

• New field on Account, set atomically with proof + num_sends after a successful prove.
• Invariant: proof.is_some() iff num_sends > 0 iff commitment_public_key.is_some().
• prev_commitment_pubkey request field stays on the wire (for backwards-compat with deployed wallets that still emit it) but is ignored.
• \"prev_commitment_pubkey required for account update\" is dropped from map_send_coins_error. The string is unreachable post-refactor; if a future regression re-introduces it, it falls through to the catch-all 500 — the pinned-and-renamed unit test surfaces it loudly.
• Migration 0012 wipes accounts (same closed-test-env precedent as 0010 / 0011): the bincode shape is non-additive, AND 0011 left post-fix(account): track per-account send counter; emit via /api/balance #129 rows in the inconsistent proof=Some, commitment_public_key=None state that would panic the AccountUpdate branch's invariant expect.

Why this is the structurally right fix

The class of bugs this eliminates: every "client-side lookup-key derivation must stay in lockstep with server-persisted state across [seed restore | app deploy | TOCTOU race]" failure mode that surfaced as a 400 / SMT collision. The server already has authoritative knowledge of which pubkey the last commitment used — putting the lookup there removes the only synchronization point that could go stale.

The wallet's numPubkeys counter still matters for choosing the next SIGNING key (the field on the request that's actually security-load-bearing). That one is fine: the server's num_sends is its source of truth, and a stale value just means the wallet would re-use an already-used pubkey on the SMT — which produces a different, caller-fixable error (Unable to get merkle proofs for provided public key, 422), not a 400 with no recovery path.

Behavioural changes

• /api/send AccountUpdate branch (i.e. account.proof.is_some()) succeeds even when the request body omits prev_commitment_pubkey or sends a stale one. The deployed zk-coins/app:beta on DEV stops 400ing without needing the app-side PR hotfix(migrations): revert ce4307c SQL comment edits to restore sqlx hash #125 (or any subsequent app deploy) to land.
• The accounts table is wiped on deploy of this PR.

Test plan

• cargo fmt --check
• cargo clippy -p node -p shared -- -D warnings
• cargo clippy -p node --all-features -- -D warnings
• cargo check --workspace --all-features --tests
• CI green (ci:full label set)
• api_remote::second_send_succeeds_without_prev_commitment_pubkey_field passes against DEV after deploy
• account_node_tests::test_send_coins_second_send_succeeds_without_prev_commitment_pubkey passes in the slim lane
• 07-send.spec.ts::send-success passes against DEV on the app side (no app-side change required — the deployed app's undefined for prev_commitment_pubkey is now harmless)

Follow-up

• zk-coins/app PR hotfix(migrations): revert ce4307c SQL comment edits to restore sqlx hash #125 can stay as-is (it now does redundant-but-harmless work). It can also be reduced to just the num_sends → numPubkeys hydration for the SIGNING pubkey — the prev_commitment_pubkey derivation branch can be dropped.
• Once every published wallet has cycled off emitting prev_commitment_pubkey, drop the field from SendCoinRequest entirely.