feat(vault): interactive TOTP two-factor auth

[UnbreakableMJ]

What

A 2FA-enabled account is no longer a dead end on the password grant. On
Error::TwoFactorRequired, Vault now prompts for the authenticator (TOTP)
code and resubmits the token grant with it — the non-API-key 2FA path.

How

• vault-api: login_password gains two_factor: Option<&TwoFactor> and
  appends twoFactorToken/twoFactorProvider/twoFactorRemember. A wrong code
  re-challenges, so callers can re-prompt.
• vault-ipc: TwoFactorCode + serde-defaulted two_factor on
  Request::Unlock (forward-compatible, like api_key/device_id).
• vault-agent: threads it into the password grant as provider 0
  (authenticator). The api-key / persisted-key branches ignore it (not
  2FA-challenged).
• vault-cli: vault login/unlock resubmit on a challenge, reading the
  code from the controlling terminal (/dev/tty) — necessary because
  read_password consumes stdin to EOF (the doc'd pass/gpg piping). --totp
  / $BW_TOTP supply it non-interactively. An empty line aborts.
• vault-tui: an "Authenticator code" step in the unlock screen — stashes
  the typed password, resubmits with the code; Tab (PIN toggle) is inert
  mid-2FA.

Scope

Authenticator/TOTP provider only. Other providers (email, Duo, WebAuthn) and
"remember this device" are tracked follow-ups. An API key still bypasses 2FA
entirely (docs/apikey.md cross-references both paths).

Tests

• vault-api: wiremock challenge → coded resubmit → token (up_to_n_times(1)
  on the challenge mock so the retry falls through to success).
• vault-ipc: Unlock.two_factor transport round-trip + absent-decodes-None.
• vault-tui: begin_2fa stashes the password and clears the field; the
  follow-up request() carries the stashed password + the code; Tab stays
  inert mid-2FA.

Local CI-exact gates all green: fmt, fresh isolated clippy -D warnings,
cargo test --workspace --all-targets under RUSTFLAGS=-D warnings,
cargo deny check (no new deps), both headless builds.

🤖 Generated with Claude Code