Plan browser and WASM unlock story

[bsutton]

Summary

Track the browser/WASM unlock story separately from native platform
secret-store integration. Browser WASM cannot directly use macOS Keychain,
Windows Credential Manager, Linux Secret Service, or KWallet, so it needs a
web-specific design.

Scope

• Keep browser builds focused on lockbox_core.
• Do not depend on native lockbox_vault platform secret-store code from WASM.
• Investigate WebCrypto for wrapping/unwrapping vault or archive secrets.
• Investigate IndexedDB as the browser persistence layer for wrapped secrets.
• Investigate passkeys/WebAuthn as an optional user-mediated unlock factor.
• Define a fallback prompt-only mode for browsers that should not persist
  secrets.

Questions To Answer

• What exact secret is safe to persist in browser storage: vault unlock
  material, a wrapping key, or only encrypted state?
• Should persisted browser unlock state be per-origin, per-user profile, or
  export/import based?
• How do we handle private/incognito sessions where persistence is unavailable
  or short-lived?
• What recovery story exists if IndexedDB state is cleared?
• Can passkeys provide a useful unlock UX without pretending they are equivalent
  to native keychain storage?

Non-Goals

• Do not try to emulate the native agent in browser storage.
• Do not persist archive content keys by default.
• Do not block native platform secret-store work on this design.

Security Notes

• Web storage is protected by browser origin and profile boundaries, not by the
  same OS facilities used by native keychains.
• WebCrypto keys may be non-extractable, but the application still runs inside
  the browser origin and must be treated accordingly.
• Browser unlock should be documented as a separate trust model from desktop
  platform secret stores.