Surfaced as a follow-up from PR #8446.
Problem
Once #8776 lands, a daemon started with `--password`/`MM_WALLET_PASSWORD` will auto-unlock on subsequent runs. But the daemon can also be started without those flags (the env-var path makes them optional in practice), in which case the persisted vault stays locked and there's no CLI affordance to unlock it.
There's also the general case of a daemon that was unlocked, then locked manually via `mm daemon call KeyringController:setLocked`, and now needs to be unlocked again.
Proposed shape
A new command at `packages/wallet-cli/src/commands/wallet/unlock.ts`:
```text
$ mm wallet unlock [--password <pw>]
```
- `--password` flag with `env: 'MM_WALLET_PASSWORD'` fallback.
- If neither is supplied, prompt interactively via `@inquirer/password` (and document the `prompts.ts` helper pattern from `packages/wallet-cli/src/daemon/prompts.ts`).
- Dispatches `KeyringController:submitPassword` over the existing daemon socket via `sendCommand`.
- Surfaces wrong-password / no-vault errors with friendly messages (mirror `mm daemon call`'s ENOENT / ECONNREFUSED hint pattern).
This is the first command outside the `daemon:` topic, so the `mm wallet` topic itself needs to be set up in the oclif config — small but non-zero scaffolding.
Acceptance
- `mm wallet unlock --password <pw>` succeeds against a running, locked daemon and `mm daemon call AccountsController:listAccounts` works afterwards.
- `mm wallet unlock` (no flag, no env) prompts and uses the supplied password.
- Wrong-password is reported as a single-line error, not a stack trace.
- Daemon-not-running is reported with the same friendly hint `mm daemon call` already uses.
- Test coverage matching the bar set by the other commands.
Context
Surfaced as a follow-up from PR #8446.
Problem
Once #8776 lands, a daemon started with `--password`/`MM_WALLET_PASSWORD` will auto-unlock on subsequent runs. But the daemon can also be started without those flags (the env-var path makes them optional in practice), in which case the persisted vault stays locked and there's no CLI affordance to unlock it.
There's also the general case of a daemon that was unlocked, then locked manually via `mm daemon call KeyringController:setLocked`, and now needs to be unlocked again.
Proposed shape
A new command at `packages/wallet-cli/src/commands/wallet/unlock.ts`:
```text
$ mm wallet unlock [--password <pw>]
```
This is the first command outside the `daemon:` topic, so the `mm wallet` topic itself needs to be set up in the oclif config — small but non-zero scaffolding.
Acceptance
Context