wallet: Make and record an init-messenger pattern decision

### Problem

The extension and mobile clients both create two restricted messengers per controller: a **controller messenger** (runtime, narrow privileges) and an **init messenger** (boot-only, broader privileges for one-shot setup steps). The wallet currently uses a single messenger per controller. Whether to adopt the two-messenger pattern is unresolved and undocumented. Without a written decision, every new controller wired into the wallet inherits this ambiguity silently.

### Proposed direction

Evaluate the trade-offs and write a short decision document (`init-messenger-decision.md`) in the wallet package recording the chosen approach and the concrete conditions under which it should be revisited. Link from the package README.

To inform the decision, gather empirical data on which messenger actions are invoked during `init()` vs. at runtime across the controllers already wired (see sub-issue for tooling). If the init-time and runtime allowlists are effectively the same, the two-messenger pattern adds boilerplate without narrowing any privileges — which favors deferring adoption.

### Acceptance

- A decision is made and written down in `packages/wallet/init-messenger-decision.md`.
- The document covers: which pattern is chosen, why, and what conditions would trigger revisiting.
- `packages/wallet/README.md` links to the decision document.

### Context

- Extension reference: `app/scripts/messenger-client-init/` — `getInitMessenger` / `getMessenger` factory pattern.
- Mobile reference: `app/core/Engine/messengers/` — same dual-factory convention.

### Subissues

- [ ] #8791