docs(arch): alknet-tls spec sanity-check fixes — client-side accessors, extraction tables, ordering

TLS spec review before task decomposition. The client side was
under-specified relative to the server side — fixed:

- W1+W2: TlsClientConfig gets the full accessor API (for_quinn,
  for_tcp_tls, rustls_config) mirroring TlsServerConfig, plus the
  local TlsIdentity input for client-auth cert presentation. Both
  clients (call + channels) consume it via the same three accessors.
- W3: Client-side extraction table for call_client.rs items that move
  to alknet-tls, including the Ed25519SigningKey / load_cert_chain /
  load_private_key duplicates that consolidate into one copy.
- W5: Server-side rustls_config() doc comment no longer claims iroh
  uses it (iroh reads the key directly).
- S6: Dropped 'remote cert type' from ClientVerifierContext — it
  doesn't drive any construction decision.
- S7: Implementation ordering note (tls first, then endpoint refactor,
  then assembly) — the call sites don't exist until step 2/3.
- N8: Noted alknet-core's acme feature + deps become vestigial.
- Flagged client spec work for the next session (two clients: call +
  channels; same TlsClientConfig shape; prerequisite for first hub).
- Advanced ADR-082/083 to Accepted; TLS README to reviewed.

docs/architecture/decisions/083-endpoint-as-accept-loop-runner.md

@@ -2,11 +2,13 @@
 
 ## Status
 
-Proposed (revised 2026-07-14: TCP+TLS moved inside the endpoint as a
+Accepted (revised 2026-07-14: TCP+TLS moved inside the endpoint as a
 third owned transport, not an external loop. This dissolves the
 multi-owner shutdown problem — the endpoint owns all its accept loops.
 `dispatch` stays public for genuinely external shapes: SSH channels,
-WebTransport streams. See §"TCP+TLS is a first-class owned transport".)
+WebTransport streams. See §"TCP+TLS is a first-class owned transport".
+All TLS-scope OQs resolved; advanced to Accepted ahead of the
+task-decomposition session.)
 
 ## Context