docs: spec-level sync with the single-publish fix + port-debt repair

The spec docs had not caught up with the stub-sweep fix commits
(4eae18f..3317ea0), and the ported docs still carried alknet
numbering that now collides with alkcall's own ADR range.

Spec sync with the landed code:
- call-protocol.md: register_imported/register_imported_all return
  Result and refuse marked specs; marked-spec registration refusal
  contract spelled out (ADR-047 am. 4 §4.8, ADR-022 am. 2026-10-13)
- client-and-adapters.md: from_call flow gains the Pub sink-forwarding
  branch and the marked-op refusal (resolves OQ-37 — no from_call
  relay wrapper; sanctioned compositions are
  ChannelRelay::register_relay_openable / ChannelClient)
- ADR-051: "channel/control is not implemented" stale sentence
  replaced with the ADR-052 per-leg control contract
- OQ-37 resolved; OQ-22 split (primitive resolved; broker placement
  out of scope) with new OQ-42 for the downstream hub broker
  (deferred(scope), concretely blocked); OQ-24 resolved by the shipped
  add/strip surface; OQ-41 → deferred(scope) with blocking condition
- README: OQ bullets renumbered to tracker IDs; alknet-collision note
  rewritten (range 001..053, alknet prefix convention); new principle
  11 (implement-or-stop-advertising); AGENTS.md ADR range 001..053

Port-debt repair:
- 149 broken decision links across 17 docs — ported with alknet
  numbers/paths, most now remapped to alkcall files by slug; the
  rest link the alknet repo per the README convention
- stale OQ numbering rewritten to tracker IDs in call-protocol.md,
  call-README.md, operation-registry.md, client-and-adapters.md,
  ADR-025, channels-overview/README/wire, channel-client
- unambiguous "alknet ADR-NNN" labels where an alknet number collides
  with an alkcall ADR (052 TTY vs channel/control, 033 storage vs
  rust-canonical, 025/026/027+020 vault vs PeerEntry/auth ADRs)

Verified: cargo test (697 + guard), fmt, clippy --all-targets -D
warnings; full markdown link scan clean.

docs/architecture/decisions/025-peerentry-and-identity-id-decoupling.md

@@ -270,7 +270,7 @@ There are three credential types in the alknet auth model:
 2. **X.509 cert** — for domain-facing endpoints (`api.alk.dev`, relays,
    ACME/Let's Encrypt). Fingerprint format: `SHA256:<hex of DER>`. Requires
    CA verification on the client side. The outgoing-only case (a client
-   connects to a public X.509 endpoint) is tracked as OQ-37.
+   connects to a public X.509 endpoint) is tracked as OQ-21.
 
 3. **Bearer token** (auth_token) — for HTTP clients that can't do TLS
    client-auth (browsers, curl), or as a secondary credential path. Carried
@@ -427,8 +427,9 @@ rotation (`PeerEntry`) or not (`ApiKeyEntry`).
   paths, and `ApiKeyEntry` is for tokens that ARE the identity)
 - OQ-29: CallClient TLS Client-Auth (resolved by this ADR's §6 fingerprint
   normalization + the client-auth wiring decision recorded in OQ-29)
-- OQ-37: X.509 outgoing-only case (the three auth types and how X.509
-  server identity fits — see OQ-37 in open-questions.md)
+- OQ-21: X.509 outgoing-only case (the three auth types and how X.509
+  server identity fits — see OQ-21 in open-questions.md; the deciding
+  ADR, alknet ADR-034, was not ported into alkcall)
 - `docs/research/alknet-storage-strategy/findings.md` §4 (the `PeerEntry`
   model and resolution path)
 - `docs/architecture/crates/core/auth.md` (the spec amended by this ADR)