docs(research): vault's SSH role is at-rest secret storage, not key derivation

A conflation in the research set: alkvault's derive-and-custody surface
(derive_ed25519, SLIP-0010 paths) was being sketched as the SSH key
path. Corrected across the docs — held SSH keys (client outgoing keys
and the server's own host key) are bearer-token-class secrets: opaque
bytes the family holds, vault-encrypted at rest, decrypted at use (the
alkhttp ADR-014 posture). No derivation story, no vault-custody
design, and the Signer-injection idea is withdrawn and recorded with
its dismissal rationale.

- auth-bridge.md: client-side gap re-framed as at-rest storage — the
  at-rest shape (OpenSSH encoding inside alkvault EncryptedData), the
  at-use lifecycle (decrypt-at-dial, one-time decode_secret_key,
  zeroized for the dial), the KeySource-like source shape
- pocs.md: POC-2 rewritten to at-rest key handling (formats comparison,
  decrypt-at-use lifecycle, locked-vault fail-closed, Signer dismissal)
- vision.md: principle 5 scoped (secret store, not key generator/custodian)
- russh.md: Signer seam noted as not presumed to be the vault shape
- AGENTS.md/CHANGELOG: convention 6 + context updated to match

Verification: cargo doc --no-deps, cargo fmt --check, cargo test
(docs-only change)

CHANGELOG.md

@@ -16,5 +16,6 @@ this crate adheres to [Semantic Versioning](https://semver.org/).
 - Phase 0 research set under `docs/research/`: `vision.md` (scope
   questions), `russh.md` (0.64.1-era inventory + pin considerations),
   `auth-bridge.md` (fingerprint → identity server path; vault-backed
-  client keys), `mapping-table.md` (channel type/request → family seam
+  at-rest client key storage — the vault as secret store, not key
+  derivation), `mapping-table.md` (channel type/request → family seam
   + feature), `pocs.md` (POC-1..3 plan — documented, not yet run).