feat: Add WASM support and browser extension infrastructure

- Add WASM build target and dependencies for all crates.
- Implement IndexedDB-based persistent storage for WASM.
- Create browser extension infrastructure (UI, scripting, etc.).
- Integrate Rhai scripting engine for secure automation.
- Implement user stories and documentation for the extension.

docs/rhai_architecture_plan.md

@@ -1,4 +1,60 @@
-# Rhai Scripting System Architecture & Implementation Plan
+# Rhai Scripting Architecture Plan
+
+## Overview
+
+This document describes the architecture and integration plan for Rhai scripting within the modular Rust cryptographic system. The goal is to enable secure, extensible scripting for both browser and (future) CLI environments, with the browser extension as the main user interface.
+
+## Interfaces
+
+- **Browser Extension**: The primary and recommended user interface for all modules, scripting, and automation.
+- **CLI**: Planned as a future feature; not a primary interface.
+
+## Vault & Scripting Capabilities
+- All cryptographic operations (sign, verify, encrypt, decrypt) are exposed to Rhai scripts via the extension.
+- Symmetric encryption/decryption of arbitrary messages/files is supported using a key derived from the keyspace password (see `Vault::encrypt`/`Vault::decrypt`).
+- User-provided Rhai scripts can access the current session's signer (with explicit approval).
+
+## Extension UI/UX & Workflow
+
+### Phase 1: Local Session & Script Execution
+1. **Session Management**
+   - User is prompted to create/unlock a keyspace and select/create a keypair.
+   - The session (unlocked keyspace + selected keypair) is required for all cryptographic actions and script execution.
+2. **Per-Keypair Actions**
+   - Sign, verify
+   - Asymmetric encrypt/decrypt
+   - Symmetric encrypt/decrypt (using password-derived key)
+   - Send transaction, check balance (with selected provider)
+   - Execute user-provided Rhai script (from input box)
+     - Scripts have access to the session manager's current signer and can send transactions on behalf of the user, but require explicit approval per script execution.
+
+### Phase 2: WebSocket Server Integration
+1. **Connection**
+   - User must have an active session to connect to the server (connects using selected keypair's public key).
+   - Connection is persistent while the extension is open; user may lock keyspace but remain connected.
+2. **Script Delivery & Approval**
+   - Server can send Rhai scripts to the extension, each with a title, description, and tags (e.g., `local`, `remote`).
+   - Extension notifies user of incoming script, displays metadata, and allows user to view the script.
+   - User must unlock their keyspace and select the correct keypair to approve/execute the script.
+   - For `remote` scripts: user signs the script hash (consent/authorization) and sends the signature to the server. The server may then execute the script.
+   - For `local` scripts: script executes locally, and the extension logs and reports the result back to the server.
+   - For user-pasted scripts (from input box): logs only; server connection not required.
+
+## Script Permissions & Security
+- **Session Password Handling**: The session password (or a derived key) is kept in memory only for the duration of the unlocked session, never persisted, and is zeroized from memory on session lock/logout. This follows best practices for cryptographic applications and browser extensions.
+- **Signer Access**: Scripts can access the session's signer only after explicit user approval per execution.
+- **Approval Model**: Every script execution (local or remote) requires user approval.
+- **No global permissions**: Permissions are not granted globally or permanently.
+
+## UI Framework & UX
+- Any robust, modern, and fast UI framework may be used (React, Svelte, etc.).
+- Dark mode is recommended.
+- UI should be responsive, intuitive, and secure.
+
+## Developer Notes
+- The extension is the canonical interface for scripting and secure automation.
+- CLI support and additional server features are planned for future phases.
+- See also: [EVM Client Plan](evm_client_architecture_plan.md) and [README.md] for architecture overview.
 
 ## Project Goal