fix(vault): drain and replay the pin retry queue #44

Summary

Failed pin-audit writes are queued in the browser but never replayed. Add a drain that retries them safely.

Estimated size: S

Motivation

A pin can succeed at the provider while the audit write fails, leaving quota accounting wrong until someone fixes it by hand.

Current state in this repo

• frontend/src/features/vault-pinning/hooks/use-pin.ts calls enqueue(...) when the audit write fails.
• frontend/src/features/vault-pinning/lib/sync-queue.ts stores entries under vault:pin_queue in localStorage; nothing reads and replays them.

Proposal

• Add drainQueue() that replays entries against /api/vault/pin in timestamp order.
• Run it on app start, on the browser online event, and from a manual retry action in the pin UI.
• Exponential backoff with a cap; de-duplicate by (cid, service, action) keeping the latest entry; stop after N failures and surface the entry in the UI.

Acceptance criteria

• A failed audit write is replayed after reconnect and then removed from the queue.
• Replaying the same entry twice does not change quota (the server write is idempotent).
• Entries that keep failing are surfaced to the user instead of retrying forever.

Out of scope

• Syncing the queue across devices.

Dependencies

• None; can be picked up independently.

Testing plan

• Unit tests with a fake fetch and fake timers (frontend/tests/*.test.mjs style, run with bun test).

Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.