Cold-start auto-consume: locked-vault deferral leaves the row in GeneratingTransaction, blocking every queued consume for 30 min

## Problem
After a browser relaunch, the first auto-consume runs before the password is entered. The loop marks the row `GeneratingTransaction` / `stage: 'sending'`, then hits the locked vault and returns without reverting the row. Since the loop skips everything while a status-1 row exists, every other queued consume is blocked. Unlocking, Claim and Retry do nothing. Rows only clear at the 30-minute reaper (all fail) or after a browser restart. Reproduced on the shipped 1.15.21 bundle; same code on main.

## Environment
Bread Wallet 1.15.21 (26cf464c), Chrome 151, testnet, auto-consume on. Extension only.

## Steps to reproduce
1. Have consumable notes pending.
2. Quit and relaunch Chrome; do not enter the password right away.
3. Open Pending notes: one row sits on "sending", the rest stay Queued behind it. Unlock/Claim/Retry have no effect.

## Root cause
- `src/lib/miden/transaction/index.ts:313-316` sets status 1 before any vault check.
- `index.ts:319` → `transaction-processor.ts:88-92` throws a locked error while the vault is null (vault is memory-only in the SW).
- `index.ts:1382-1386` catches it and returns with no status revert.
- `index.ts:1335-1338` then skips every pass while the status-1 row exists; no unlock hook re-drives it.

Introduced by #375 (fix for #313), which widened the pre-existing non-reverting arm from #268. Related downstream symptom: #771.