[PLAN] Prepare GoodWallet for GoodWidget integration

[L03TJ3]

[PLAN] Prepare GoodWallet for GoodWidget integration

Parent feature request: #52

Required behavior

• Establish a reusable, authenticated GoodWidget integration boundary in GoodWallet using only the runtime, dashboard, route, host, provider, and focused-test work from GoodWallet PR Setup support and ci/cd handling updating and integrating verified production released widgets #51.
• Keep src/widgets/registry.ts as the typed, reviewed source for exact package identity/version, literal entry imports, integration mode, route, label/icon, chains, and EIP-1193 methods.
• Reject duplicate widget IDs/routes, unsupported chains/methods, and non-exact package versions.
• Reuse the existing dashboard grid
• Mount registered widgets through an authenticated bottom-sheet route following src/app/[locale]/@home/(home)/(bottomsheet)//page.tsx.
• Default to a Web Component host, permitting React only when explicitly selected in a reviewed registry entry; both hosts must lazy-load client-side and receive { provider, themeOverrides, config }.
• Assign Web Component object properties without HTML serialization and clear them on unmount.
• Expose only a restricted EIP-1193 provider; enforce each widget’s approved method subset and chains at runtime, and never expose signer, seed, unrestricted RPC provider, or session internals.
• Keep signing-capable widgets disabled until every signing/transaction request validates active account and chain and receives explicit Wallet-owned approval.

Execution steps

1. Review only the designated runtime/dashboard/provider portions of GoodWallet PR Setup support and ci/cd handling updating and integrating verified production released widgets #51 and the listed reference paths; exclude workflows, agents, release/dispatch scripts, CODEOWNERS, and automation documentation.
2. Add the reusable src/widgets/** registry, authenticated route, renderer, host contract/property handling, React/Web Component hosts, and provider policy boundary.
3. Integrate registry actions into src/sections/Home/components/WalletSection.tsx and reusable icon support into src/components/Form/RoundButton/RoundButton.tsx while preserving the six core actions and More-drawer behavior.
4. Add the bottom-sheet route and ensure it mounts only registered, authenticated widget entries.
5. Add focused unit coverage for registry validation, host selection, object-property handoff/cleanup, provider restrictions, chain/account validation, and provider errors.
6. Add desktop and mobile Playwright coverage for authenticated widget opening from both the dashboard and More drawer without regressing layout behavior.
7. Run type checking, unit tests, production build, and Playwright tests.

Acceptance criteria

• Typed registry validation covers duplicate IDs/routes, unsupported chains/methods, and non-exact versions.
• Web Component mode is default; React mode is opt-in through one reviewed registry entry.
• Dashboard integration preserves the existing grid, More drawer, six core actions, and responsive layout.
• Authenticated bottom-sheet route mounts registered widgets without widget-specific session code.
• Hosts lazy-load client-side, share the same contract, and clean up Web Component object properties.
• Runtime policy restricts every widget to reviewed methods and chains; signer, seed, unrestricted provider, and session internals remain inaccessible.
• Signing/transaction requests cannot proceed without active-account and chain validation plus explicit Wallet-owned approval.
• Unit, desktop/mobile Playwright, type-check, production-build, and required test suites pass.

Human reviewer checklist

• Confirm the PR Setup support and ci/cd handling updating and integrating verified production released widgets #51 scope is limited to the stated runtime/dashboard/provider work and excludes release-to-Copilot automation.
• Confirm registry entries use exact package versions, literal imports, reviewed routes, chains, and methods.
• Confirm the runtime provider boundary enforces policy rather than trusting registry validation alone.
• Confirm no widget receives signer, seed, unrestricted RPC access, or session internals.
• Confirm signing-capable widgets remain disabled unless Wallet-owned approval is present.
• Confirm the widget-specific integration remains a separate follow-up.