fix(consent): derive the approver's match code from the digest, not its encoding

[stormer78]

Pairs with OpenVTC/verifiable-trust-infrastructure#911 — must land together

Trust Tasks 0.4 moved payloadDigest to the shared DigestMultibase type and landed it errata-style, in place on task-consent/{request,decision,granted}/0.1. The type URI did not move, so no version check on either side detects this — the encoding is the only signal.

The digest is what the approver signs and what the executor re-derives. A mismatched pair produces an approval that is given, accepted by the human, and then silently never takes effect. This should not merge before #911, and #911 should not merge without it.

What was wrong

The approver screen took the first six characters of payloadDigest as the code the human matches across two devices. Under base58btc every SHA-256 digest begins zQm — the multibase marker plus the 0x12 0x20 multihash prefix, constant for every digest ever produced:

zQmcdLJ…   zQmRTnb…   zQmb7oR…   zQmbu6r…      ← four different payloads

Half the code would have been a format marker: ~17.6 bits where the human believes they are comparing ~35, while still looking like six random characters. That is the one check on this screen a hostile device cannot defeat — every other check assumes an honest device; only a comparison the human performs across two independent screens moves the check somewhere the device cannot reach.

What this does

matchCodeFromDigest (new, packages/core/src/trust-tasks/digest.ts) decodes the multibase, strips the multihash prefix, and hex-renders the leading bytes. Because the digest is still SHA-256, this reproduces exactly the six characters this surface showed when the wire carried bare hex — so the migration is invisible to the operator and neither repo strands what the other already has on screen.

It agrees character-for-character with vta_mobile_core::consent::match_code_from_digest in #911. The fixture zQmSK9pGKFnmc77pqyNAPJyPKt8rMqctngfg3vwuMArwGYZ → 3b0c7f is asserted in both repositories and is the contract between them.

• Fails closed on an undecodable digest. No code rendered, no type-to-confirm input, approval blocked, and the user is told why. A stale hex digest from a version-skewed agent fails here rather than at the executor after the human has already agreed.
• Keeps the case-insensitive compare, now correct rather than accidentally so — the derived code is hex. Lowercasing base58 would have widened the match.
• Accepts every base the ^[zumbfF] pattern admits, so a conforming digest from a non-VTA executor is not refused. An unrecognised prefix is refused rather than guessed at.
• Reuses the base58btc decoder already in trust-tasks/canonical.ts.
• payloadDigest is still echoed verbatim into the decision, which #911's round-trip test requires.

9 new tests in packages/core/tests/trust-tasks.digest.mjs, including the shared fixture, the hex(digest)[..6] continuity property, bare-hex refusal, and 64 payloads → 64 distinct codes.

Dependency refresh (same PR, by request)

Everything in range; npm outdated is now empty. react 19.2.8, vite 8.2.1, @scure/base 2.3.0, @noble/* 2.3.0, @types/chrome 0.2.5, lucide-react 1.31.0, and others.

⚠️ vite 8.2 dropped esbuild, and vite-plugin-top-level-await@1.6.0 (already latest) requires it without declaring it — the extension build fails with Cannot find module 'esbuild'. Added esbuild as an explicit extension devDependency. That dependency is now load-bearing for the build; it can come back out if the plugin ever declares it properly.

The MV3 invariant was re-checked by hand across the vite bump: dist/background.js is still a single 88.52 kB bundle with no dynamic import().

Two notes for #911's author

1. #911's description contradicts its diff. The "Known follow-up, deliberately not fixed here" section says the match code was left alone; the diff adds match_code_from_digest and rewires parse_task_consent_request to it. That section is the one a reviewer needs in order to realise this repo has to move.
2. #911 pins trust-tasks-rs 0.4.0, but 0.4.1 and 0.5.0 have since shipped. I checked — they add the ceremony envelope member and the /ceremony/ namespace, not a further digest change. This PR is unaffected either way.

Pre-merge checklist (vti-stack-development-guide §9)

- [x] No new reqwest::Client::new() / bare fetch(); all clients have finite timeouts (R1.2) — no network code touched
- [x] No lock held across a network await (R1.3) — n/a
- [x] No local state committed before its remote effect, or the flow is resumable with an idempotency key (R2.1) — n/a, pure decode + render
- [x] Every retry is bounded + backed off; non-idempotent ops are not blind-retried (R1.4) — n/a
- [x] Accept/poll/listen loops survive transient errors (R1.5) — n/a
- [ ] Acks/deletes happen only after durable handoff (R1.6) — still violated repo-wide (see CLAUDE.md "Known open defect"); not touched or worsened here
- [x] New/changed wire types: camelCase, deny_unknown_fields where security-relevant, schema registered, all consumers (incl. JS) updated (R3.*) — `payloadDigest` encoding change coordinated with #911; both consumers updated, shared fixture asserted in both
- [x] Config absence = most restrictive; fail-closed if enforcement can't start (R5.*) — an undecodable digest blocks approval rather than degrading the check
- [x] Logs/status claim only what was verified; background-job failures are surfaced (R6.*) — the screen states plainly when it cannot read a digest instead of rendering a plausible code
- [x] "Process dies on the next line" answered for every mutation touched (R2.1) — no mutations
- [x] Deviations from this guide flagged explicitly with rule numbers — R1.6 above; R4.1 is the reason this is cross-linked to #911