feat(vault): disclose fork deploy-key risk and guide version recovery

[mellowcroc]

This PR adopts the creator-trust policy for F-2026-19216 and F-2026-19225. A Mina transaction-version upgrade can make the vault's deploy key sufficient to replace its verification key without owner approval. The creation flow now warns the creator, requires acknowledgment, and offers a plaintext key download for offline backup. Every vault detail page warns owners about that authority and the risk of stranded funds if a fork breaks existing proofs and the key was lost. Owners who do not trust the key holder are directed to move funds before an upgrade.

For a vault whose stored transaction version is older, the UI shows the path supported by its on-chain VK:

• Installed VK matches the release: Owners can try a normal proved vault action, then check whether Mina refreshed the stored version. The UI and backend allow this only when the VK matches the reviewed release and the sole permission mismatch is the older version. The first applied Vault account update ends the deploy-key fallback, even if the VK is unchanged. Anyone can pay for an authorization-free no-op because Vault access is none; the UI advises a real proved action to confirm the existing proof still works after the fork.
• Installed VK differs from the release: The UI exports a separate v2 migration request. A matching MinaGuard offline CLI release compiles and checks the replacement VK, then signs a single VK update with the saved deploy key and an offline fee payer key. The UI validates the signed command and fresh node state before broadcast, and checks the on-chain result afterward. If old proofs fail, this migration must land before any other Vault account update. A third party can pay for a no-op that refreshes the version first, leaving the broken VK installed and closing this saved-key migration path. The panel warns that a maintainer must publish a compatible release and that the browser cannot authenticate the offline binary. Migration uses an action-specific v2 request and response; current owner requests use v2 and their signed responses remain v1. Older v1 owner requests must be re-exported with matching UI and CLI releases.

This provides disclosure and a deploy-key recovery path under the accepted trust policy; it does not add a quorum-approved upgrade. A future fork still requires a reviewed compatible circuit, matching UI and CLI releases, and per-network VK hashes. No post-fork transaction acceptance is claimed.

The self-hosted E2E runner now installs Chromium without rerunning its OS dependency installer, which was failing on an unrelated apt source before tests began.

The creation warning includes the optional deploy-key backup:

The same-VK panel guides a proved action and an on-chain version check:

The different-VK panel explains the offline CLI release requirement before migration:

The two post-fork screenshots use mocked older-version node responses and are illustrative.

[graikos]

Code looks good. Two things before merge.

1. Rebase on main. fix: show the SubVault configuration before a CREATE_CHILD approval #164 moved owner bundles to version 2, so your "owner actions require version 1" check collides with the migration format. Check owner bundles against OFFLINE_REQUEST_VERSION, tell migration apart by its action, and replace docs: scope the verification-key pin to the transaction version #163's row 9 outright, since its "cannot be re-stamped" sentence is wrong.

2. Wording. Mina's transaction logic runs set_txn_version_to_current on every applied vault update, and access is None, so anyone can refresh the version with a no-op. After a proof-preserving fork the window closes on the first update by anyone. After a proof-breaking fork, the saved-key migration must land before any other update, so a third party can seal the vault for a fee. Please say so, and keep the advice to use a proved action rather than a no-op.

[graikos]

Correction: point 1 is already handled by f92cb89, which I missed. Owner and migration bundles now share OFFLINE_REQUEST_VERSION and are told apart by action, and row 9 replaces #163's wording. That works for me. Only point 2, the wording about who can refresh the stored version, remains.