wallet-cli: Auto-unlock the keyring on subsequent daemon starts

[sirtimid]

Today the wallet-cli daemon imports the SRP on first run (which leaves the keyring unlocked) but on subsequent runs it just hydrates state from `/wallet.db` and constructs the `Wallet`. The persisted `KeyringController.vault` is reused, but `KeyringController.isUnlocked` is `persist: false` and defaults back to `false`.

Net effect: after a daemon restart the wallet starts locked, and any messenger action that touches keyring-bound state (`AccountsController:listAccounts`, signing, etc.) fails. The daemon already has the password from the `--password` flag / `MM_WALLET_PASSWORD` env var, so the user can't actually use a restarted daemon without manual intervention.

Proposed fix

In `packages/wallet-cli/src/daemon/wallet-factory.ts`, after `subscribeToChanges` and the existing `if (wasFirstRun)` branch, call `KeyringController:submitPassword` on the not-first-run path:

```ts
if (wasFirstRun) {
await importSecretRecoveryPhrase(wallet, password, srp);
} else {
await wallet.messenger.call('KeyringController:submitPassword', password);
}
```

Acceptance

• A daemon that was started once, killed, and started again responds successfully to `mm daemon call AccountsController:listAccounts` without re-importing the SRP.
• Wrong-password case is surfaced as a clean startup error (likely propagated from `submitPassword`) rather than a wedged daemon.
• New test in `wallet-factory.test.ts` covering both branches.
• Optional follow-up: add a `mm daemon unlock` command for daemons started without `--password`.

Context

• Surfaced during PR feat(wallet-cli): Add wallet CLI with daemon support #8446 review as the single biggest user-visible gap in the CLI today.