Port alknet-vault crate from alknet

Copy the local key vault (src/, tests/) verbatim from
alknet/crates/alknet-vault and create a standalone Cargo.toml
(workspace-inherited fields inlined). Port the architecture docs
(specs, ADRs 018-026, OQs 020-022) from alknet's nested multi-crate
layout to a flat single-crate layout, fixing relative link paths.

ADR and OQ numbers are preserved from alknet; a subsequent pass will
renumber them to a per-project sequence (001, 002, ...) and rebrand
alknet-vault -> alkvault (crate name, lib name, prose), updating the
cross-references to non-vault alknet ADRs (003, 005, 008, 010, 014,
064) that are referenced in the copied docs but not copied over.

Build, 108 tests, and clippy all pass clean.

docs/architecture/questions/022-key-rotation-mechanism.md

@@ -0,0 +1,8 @@
+# OQ-22: Key Rotation Mechanism
+
+- **Origin**: [encryption.md](../encryption.md)
+- **Status**: resolved
+- **Door type**: One-way (path scheme), two-way (rotation policy)
+- **Priority**: medium
+- **Resolution**: Key rotation uses version-indexed derivation paths. Each key version maps to a distinct SLIP-0010 path: `m/74'/2'/0'/{version-2}'`. v2 (current) is at `m/74'/2'/0'/0'`; v3 is at `m/74'/2'/0'/1'`; etc. The `decrypt` method derives the key at the path indicated by `encrypted.key_version` (not always at `PATHS::ENCRYPTION`). The `rotate` method decrypts with the old version's key and re-encrypts with the new version's key — no new mnemonic needed. The assembly layer or a migration tool iterates stored blobs and calls `rotate` on each; the vault does not self-rotate. Partial rotation is safe (old keys remain derivable). See ADR-021.
+- **Cross-references**: ADR-020, ADR-021, [encryption.md](../encryption.md), [service.md](../service.md)