docs(arch): sync call-completion specs with implementation — Dispatcher/RemoteFilter, ClientError, OQ-29

Post-implementation spec sync after the call-completion batch landed
(commits e4a2594..a3825f5). The sub-agent review flagged no spec drift, but
comparing the implemented types against the spec sketches surfaced five
details the specs didn't name — filled in here so the spec matches what was
built:

- client-and-adapters.md: name the shared Dispatcher (protocol/dispatch.rs)
  + RemoteFilter mechanism that enforces ADR-028's default-deny at dispatch
  time (the load-bearing security gate — checks remote_safe before building
  context, before any capability material reaches the handler). Add
  ClientError/RemoteIdentity types, the spawn_dispatch lower-level API, and
  the services_list_handler_peer_scoped wiring (the assembly layer must
  register the peer-scoped services/list handler for a CallClient's registry,
  not the plain one). Record the v1 TLS client-auth gap (AcceptAnyServerCertVerifier,
  with_no_client_auth) as OQ-29.
- call-protocol.md: point the adapter dispatch-loop description at the shared
  Dispatcher (dispatch.rs) so readers find the mechanism ADR-017 §1 commits to.
- open-questions.md: OQ-29 — CallClient TLS client-auth + remote-identity
  verification is a two-way-door remainder; the no-env-vars invariant is
  unaffected (auth_token flows via call-protocol payload, not TLS).
- READMEs: current-state now reflects completion done + reviewed (207 lib +
  2 integration tests); OQ-29 added to both OQ summaries.

docs/architecture/crates/call/call-protocol.md

@@ -164,6 +164,15 @@ The adapter:
 5. Writes response `EventEnvelope` frames back to the appropriate stream
 6. Manages the `PendingRequestMap` for outgoing calls
 
+The dispatch loop is **shared** with `CallClient` (ADR-017 §1): both
+`CallAdapter::handle` (accept path) and `CallClient::connect` (connect path)
+construct a `Dispatcher` (`protocol/dispatch.rs`) and call `run_loop` — the
+dispatch half is one implementation, the connection-establishment half differs
+(accept vs dial). The `Dispatcher` carries a `RemoteFilter` (ADR-028) that
+gates dispatch by `remote_safe`; the accept path uses `RemoteFilter::trusted()`
+by convention. See [client-and-adapters.md](client-and-adapters.md) for the
+`Dispatcher`/`RemoteFilter` mechanism.
+
 ### Stream Model
 
 See ADR-012 for the full rationale.
@@ -538,6 +547,7 @@ See [open-questions.md](../../open-questions.md) for full details.
 - **OQ-16** (resolved by ADR-014): No vault operations are exposed over the call protocol for now.
 - **OQ-19** (resolved): Session-scoped operation registries — agent-written operations overlaid on global registry via `OperationEnv` trait layering. Protocol doesn't need changes; `OperationEnv` must remain a trait.
 - **OQ-25..28** (open, two-way): Call-completion remainders — `CallClient` remote-safe marking shape, `OperationAdapter` error type, `from_call` re-import trigger, `from_call` namespace collision. The `CallClient`/adapter surface itself is specced in [client-and-adapters.md](client-and-adapters.md); the one-way door among these (existence of default-deny filtering) is resolved by ADR-028.
+- **OQ-29** (open, two-way): `CallClient` TLS client-auth + remote-identity verification — v1 connects with `with_no_client_auth()` and `AcceptAnyServerCertVerifier`; wiring RawKey client-auth and a real `ServerCertVerifier` is additive. See [client-and-adapters.md](client-and-adapters.md).
 
 ## References