feat(extension): Browser extension prototype

[wjbeau]

Pull Request Template

Description

Implements a prototype of a browser extension based on react-native-web. Broadly it is a fully featured version of Pera Wallet, but some UX/UI cleanup and lots of QA is still missing.

Notable issues remaining:

• Some outstanding review items from the code review of this PR captured in docs/EXTENSION_REVIEW_FOLLOWUPS.md temporarily for follow up PR to resolve and remove
• Ledger signing doesn't work yet - ledger is discoverable and accounts can be added but the signing flow gets stuck
• Various UI/UX issues with web vs native affordance (e.g. slide to confirm doesn't work as well on web)

Related Issues

N/A

Checklist

• Have you tested your changes locally?
• Have you reviewed the code for any potential issues?
• Have you documented any necessary changes in the project's documentation?
• Have you added any necessary tests for your changes?
• Have you updated any relevant dependencies?

Additional Notes

• Add any additional notes or comments that may be helpful for reviewers.

[yasin-ce]

Offscreen storage-shim receiver has no sender check — asymmetric with the hardened host.

This receiver accepts any runtime message whose scope === STORAGE_EVENT_SCOPE and fans it straight into the persist listeners:

chromeLike.runtime.onMessage.addListener((message: unknown) => {
    const msg = message as StorageChangedBroadcast | undefined
    if (msg?.scope !== STORAGE_EVENT_SCOPE) return undefined
    listeners.forEach(listener => listener(msg.changes, msg.areaName))
    return undefined
})



---

**Comment 2 — `extensions/platform-chrome/src/dapp/permissions.ts` (`grant` / `revoke` / `pruneAddresses`)**

```markdown
**Permission-store mutators are read-modify-write with no compare-and-swap.**

`grant`, `revoke`, and `pruneAddresses` all do `map = await readMap()` → mutate → `await writeMap(map)` against a single `chrome.storage.local` key with no locking. Since the SW is event-driven and these are all `async`, two overlapping ops both read the pre-mutation map and the later `writeMap` wins.

Concrete case: a `revoke` (or `pruneAddresses` stripping a just-deleted account) interleaves with a concurrent `enable`/`grant` — if `grant` read the map before the `revoke`/prune wrote, `grant`'s write resurrects the revoked origin / pruned address. `pruneAddresses` is a security-cleanup path (removing deleted accounts from dapp grants), so losing it is the meaningful case: a revoked dapp stays connected, or a deleted account's address stays authorized.

Serialize the mutators (a simple write queue / mutex, or a read-CAS-retry loop on the storage key).