Update extension architecture status

docs/architecture.md

@@ -2,7 +2,7 @@
 
 ## Product and implementation status
 
-One browser extension hosts four tabs: Nostr (identities, events, relays), Wallet (BTC accounts, balances, transaction review), Inscribe (content and commit/reveal transaction preparation), and Chain (chain inspection and isolated test-network experiments). The current vanilla-JS shell provides navigation only. The following is a design contract, not implemented cryptography or a working wallet.
+One browser extension hosts four tabs: Nostr (identities, events, relays), Wallet (BTC accounts, balances, transaction review), Inscribe (content and commit/reveal transaction preparation), and Chain (chain inspection and isolated test-network experiments). v0.2 implements the first narrow wallet boundary for Super Testnet: an extension-owned test Taproot key, page provider bridge, semantic approval popup, and commit/reveal signing. Nostr, real-network custody, encrypted vaulting, and generalized wallet RPC remain design work.
 
 ## Shared primitives and key hierarchy
 
@@ -10,13 +10,13 @@ A single master seed belongs to an extension-private vault. A BTC derivation ada
 
 All tabs use one shared key service, signing service, encrypted storage service, and network configuration. Feature adapters construct requests and consume public keys, addresses, signatures, and transaction results. They never accept the master seed as a parameter. Only the trusted vault/derivation/signing boundary handles secret bytes. Keep plaintext keys out of logs, DOM, sync storage, error messages, telemetry, and content scripts. Persist only authenticated encrypted vault data, with reviewed password KDF parameters and versioned migrations. Locking and background-worker suspension must clear in-memory authority and require unlock again; JavaScript cannot guarantee physical memory erasure.
 
-The initial shell requests no permissions and has no vault or background worker. Introduce a trusted extension worker and narrowly scoped storage permissions only when implementing these primitives. Backup/recovery, auto-lock, unlock UX, and corruption recovery require explicit design before real funds.
+The extension now has a trusted Manifest V3 service worker plus `storage` permission for a **test-only** Super Testnet key. This is intentionally not the future production vault: it is unencrypted local extension storage and must never hold real funds. Backup/recovery, auto-lock, encrypted vaulting, unlock UX, and corruption recovery remain gates before any real-network key.
 
 ## Requests and trust boundaries
 
 Planned flow: site/agent → untrusted bridge → trusted extension request validator → permission and confirmation UI → key/signing service → bounded response. Do not expose generic key export, seed access, arbitrary derivation, or unrestricted signing RPCs. Bind grants to authenticated sender origin, account/identity, network, operation, expiry, and appropriate spending/rate limits. Validate schemas, sizes, sender provenance, replay protection, and revocation on every request. A claimed origin inside a payload is not authentication.
 
-For BTC, review transaction outputs, fees, inputs, network, and change before signing; distinguish signing from broadcast authorization. For Nostr, constrain event kinds and identity and show the event being authorized. NWC connection credentials are secrets too; keep them inside the vault and expose only budgeted, expiring payment capabilities. No site/agent bridge or NWC integration exists yet.
+For BTC, review transaction outputs, fees, inputs, network, and change before signing; distinguish signing from broadcast authorization. For Nostr, constrain event kinds and identity and show the event being authorized. NWC connection credentials are secrets too; keep them inside the vault and expose only budgeted, expiring payment capabilities. A narrow site bridge now exists for `supertestnet.lol` and localhost development: `bitcoin_getAccounts`, `bitcoin_getNetwork`, and `ord_signInscription`. Signing requests are origin-bound by the content-script match plus service-worker validation and require an extension approval window. NWC integration does not exist yet.
 
 Treat relay events, inscription content, and chain responses as untrusted data; render text safely and isolate active content. Chain experiments must use explicit network selection and separate account contexts, never silently route mainnet funds into a sandbox.
 
@@ -33,4 +33,4 @@ Unsquashed Git subtrees preserve original commit identities and ancestry while p
 3. Implement encrypted vault, lock lifecycle, and signing policy with failure-path tests.
 4. Adapt each feature against shared primitives, beginning with explicit test networks.
 5. Add bounded external capabilities only after origin, consent, expiry, replay, and revocation tests.
-6. Test loading, navigation, CSP, and lifecycle in supported browsers before release.
+6. Test loading, navigation, CSP, and lifecycle in supported browsers before release.