docs: add Vault SecretProvider requirements spec (Use Case A)

[Alan-Cha]

Summary

Adds the requirements/design spec for config-time Vault secret resolution (Use Case A), per the scope agreed in #144's closing comment.

• Provider-agnostic SecretProvider trait + kind()-based factory/registry, with VaultProvider as the sole implementation shipped here
• Vault KV v2 reads only, via a hand-written reqwest client (no SDK, no codegen)
• Kubernetes and AppRole auth, explicitly selected, no default
• Fail-fast initial resolution; time-interval refresh with last-good fallback on failure, decoupled from Vault's own auth-token renewal lifecycle
• JWT decoding keys (DecodingKeySource::Provider) as the first and only consumer
• Opt-in secrets-vault feature, out of default, in full

Runtime/per-request delegation (Use Case B), dynamic secrets, KV v1, writes, and codegen are explicitly out of scope — carried forward from #144's spike.

Follows the same structure/conventions as docs/brainstorms/valkey-session-store-requirements.md (Problem Frame → Actors → Key Flows → Requirements → Acceptance Examples → Success Criteria → Scope Boundaries → Key Decisions → Dependencies/Assumptions → Outstanding Questions). Two citation corrections were made during review before this PR: R13's JwksUrl soft-boot citation was pointing at the wrong file (resolver.rs, not config.rs), and R17's "mirrors valkey exactly" claim on the cpex-plugin-<name> naming convention was corrected — valkey's actual optional dependency is cpex-session-valkey, which doesn't itself follow that convention.

Six items remain deferred to planning, enumerated under Outstanding Questions — the provider-construction-ordering seam (R4) is the one that blocks everything else.

Closes #144.

Test plan

• N/A — documentation only, no code changes

🤖 Generated with Claude Code