docs(architecture): resolve review #002 remaining Tier 4 findings

Add ADR-026 (vault key model — HD derivation) recording the foundational
HD-derivation decision, 74' coin type reservation, SLIP-0010/Ed25519
default, secp256k1 feature-gating, and AES-256-GCM cipher choice. These
were previously inline rationale with no ADR (W9).

Extend ADR-018 with an explicit EncryptedData wire format lock — fields,
encoding, and semantics are frozen; no removal without a format-version
migration (W10).

Resolve the remaining guard clauses and spec decisions:

- W2: Capabilities must be immutable after construction (no interior
  mutability). Makes the Arc vs deep-copy clone semantics genuinely
  two-way.
- W5: Published to_* specs are compatibility contracts — best-effort
  mappings are two-way before first publication, one-way after. Version
  generated specs.
- W6: Salt field clarification — v2 salt is permanently unused; a future
  KDF is a different derivation family, not a version-indexed path; the
  field saves a wire-format change only.
- W7: unlock_new returns Zeroizing<String> — the mnemonic is the root of
  trust and must not linger in freed memory.
- W17: OQ-09 WASM — server-side dispatch door is honestly closed
  (Connection is concrete, tokio-bound), not implicitly preserved.
- W18: OQ-10 git — composability fork (raw smart protocol vs call-protocol
  projection) is a separate decision from ERC721 scope.
- W20: from_openapi must prefix imported error codes (HTTP_404) to avoid
  collision with protocol-level codes (NOT_FOUND). Normative rule, not
  naming convention.
- W21: ScopedOperationEnv field is private — construction via new()/
  empty(), query via allows(). Makes the future subgraph refactor
  non-breaking.
- C13: Connection::set_identity — the endpoint does not read identity()
  after handle() returns (Connection is moved into the spawned task).
  Observability is handler-side logging. Simplest honest answer.
- W1: OperationAdapter trait is async, returns Vec<HandlerRegistration>.
  from_call requires async discovery; ADR-022 changed the return type.
- W11: CompositionAuthority::as_identity() defined — constructs a
  synthetic Identity (label as id, scopes, resources) not resolvable via
  IdentityProvider. Second Identity construction path, acknowledged.
- W14: SecretKey is iroh::SecretKey (Ed25519) — consistent with the
  endpoint's iroh dependency.
- W19: Grandchild abort propagation is inherit-by-default (option a) —
  invoke() with no explicit policy inherits parent's policy. ContinueRunning
  auto-propagates to grandchildren unless explicitly overridden.

docs/architecture/decisions/020-hd-derivation-for-encryption-keys.md

@@ -153,8 +153,20 @@ not a bug. The migration tool handles the TS→vault transition.
 If a future use case requires KDF-based key derivation (e.g., stretching a
 key derived from a non-seed source, or using a salt for additional domain
 separation), it would be a new key_version with its own derivation method.
-The `salt` field is available for this. This is additive — it doesn't
-change v2 data. See OQ-22 (key rotation).
+The `salt` field is available for this.
+
+**Clarification (review #002 W6)**: the salt field is reserved for *future
+versions'* use. v2 data's salt is permanently unused — it was random, never
+participated in key derivation, and cannot be retroactively made
+load-bearing for v2 data. Introducing a KDF in v3 is a new derivation
+method (not a version-indexed path), requiring its own design and a v2→v3
+migration (re-encrypt with the new KDF, using a newly-generated v3 salt —
+the v2 salt is not reused). The field's presence saves a wire-format struct
+change only (ADR-018 locks the wire format); it does not make the KDF
+design or migration trivial. A KDF doesn't fit the rotation scheme
+(version-indexed paths, ADR-021) — it's a different derivation *family*,
+not another version index. See OQ-22 (key rotation) and ADR-018
+(`EncryptedData` wire format lock).
 
 ## Consequences