)

The MCP OAuth auth_start handler stores PKCE state across three
sequential vault_set calls (pkce_verifier → pkce_state → redirect_uri).
The first call lazy-creates the vault via init() + set(); every
subsequent call walks unlock() + set() against a fresh CredentialVault
instance constructed inside KernelOAuthProvider::vault_set. Pre-fix the
second call's unlock() failed with aead::Error because init() duplicated
the env / keyring lookup code from resolve_master_key(). The two sites
could resolve different master keys on container hosts where DBus is
partially available or env mutation races with the vault unlock, leaving
a file the same process could not decrypt one call later.

Two changes:

1. init() now resolves the master key through resolve_master_key()
   directly. The random-key fallback only kicks in when
   resolve_master_key() returns VaultLocked (no env, no keyring), and
   that branch stores the generated key into the keyring so subsequent
   resolves on fresh instances find the same value. By construction the
   two code paths can no longer diverge.

2. init() now performs a post-write verification: it constructs a
   sibling CredentialVault::new instance and calls unlock() on the
   freshly-written file. If unlock fails, init() rolls back the file
   and returns an actionable Vault error pointing at the divergence
   rather than letting the next vault_set caller fail downstream with
   an opaque aead::Error. This also catches an AAD path-binding
   regression (issue hypothesis #2) at the source.

Regression coverage:

- vault::tests::init_then_set_then_reopen_unlock_via_env_key pins the
  init() + set() -> fresh-instance unlock() round trip via the
  env-resolved master key, mirroring the failing auth_start sequence.
- mcp_oauth_provider::tests::vault_set_twice_round_trips_via_env_key
  exercises the same flow through KernelOAuthProvider::vault_set --
  the exact API the auth_start handler calls -- and reads every entry
  back through a fresh provider instance to confirm no entry is lost
  across the re-open boundary.

Verification:
- cargo check --workspace --lib
- cargo clippy -p librefang-extensions -p librefang-kernel --lib --tests -- -D warnings
- cargo test -p librefang-extensions (87 passed)
- cargo test -p librefang-kernel --lib vault (10 passed, including
  cross-test interaction with vault_cache_reuses_unlocked_handle_across_calls)
- cargo test -p librefang-api --test mcp_auth_routes_extra_test (8 passed)

Addresses code review on #5074.

- new vault::tests::init_env_mutation_during_save_rolls_back_and_surfaces_typed_error
  test: a worker thread mutates LIBREFANG_VAULT_KEY between init's
  resolve_master_key() and init's post-write verify-unlock, proving
  the verify-unlock catches the divergence, rolls back the corrupt
  vault.enc, and surfaces a typed ExtensionError::Vault(_) naming the
  divergence (not a bare aead::Error). Verified failing on origin/main
  (pre-fix init() returns Ok silently and the test's expect_err panics)
  and passing on this branch.
- align serial_test groups: vault_set_twice_round_trips_via_env_key
  (mcp_oauth_provider), vault_cache_reuses_unlocked_handle_across_calls
  and install_integration_writes_through_cached_vault_handle
  (kernel::tests) all move to #[serial_test::serial(librefang_vault_key)]
  so every test in librefang-kernel that mutates the process-global
  LIBREFANG_VAULT_KEY sits in one named group. Two disjoint serial
  groups in the same crate could otherwise race the env var.
- tone down init() doc-comment speculation about whitespace tolerance
  and Zeroizing-vs-String temporary lifetimes — neither path strips
  whitespace and neither is optimizer-sensitive at env-read. Replace
  with the concrete failure mode: env mutation between init's save
  and the next unlock's read.
- log on rollback unlink failure with tracing::warn (path, error).
  EACCES would otherwise silently leave a corrupt vault.enc that the
  next init() rejects with "Vault already exists"; operators need
  visibility into the residue.
- drop redundant drop(verify) — the block-scope drop runs anyway.