wallet: Add injectable `logger` to `WalletOptions` for initialization diagnostics

@grypez is already working on this.

Since May 26, 2026.

Sub-issue of #8790.

### Problem

There is no visibility into the order or timing of controller initialization. This makes it impossible to observe empirically which messenger actions are called during `init()` vs. at runtime — information needed to make the init-messenger pattern decision tracked in #8790.

### Proposed direction

Add an optional `logger?: Pick` field to `WalletOptions`. When provided, `initialize()` should call `logger.info(`[wallet] ${name}: initialized`)` immediately after each controller's `init()` call returns. The field should be no-op by default so library consumers are unaffected.

Passing `console` during development then gives a timestamped breadcrumb trail. Any messenger action call observed before a given controller's init-complete log is a candidate for an init messenger; calls observed after are runtime uses.

### Acceptance

- `WalletOptions.logger` is optional and defaults to no output.
- `initialize()` emits `[wallet] ${name}: initialized` via `logger?.info` after each controller init completes.
- Existing tests pass unchanged.
- Passing `{ info: console.info }` during a development run produces one log line per wired controller in initialization order.