docs(arch): workspace scope correction (ADR-085) + tls spec review fixes

ADR-085 records the actual workspace scope: the mono-repo is the core
networking toolkit (substrate: core, tls, call, channels; deployment
shapes: hub, worker; foundational handlers: tty, http, ssh, tunnel,
socks5, fs, sftp; vault). Consumer repos (docker, agent) are separate
repos depending on the published core crates. The overview's crate
graph had been describing the wrong scope since ADR-003 — a flat
~12-crate workspace including DNS/messaging/NAPI while omitting
channels, hub, worker, and tls. This stale scope was a causal factor
in the 'assembly layer' hedging pattern: when the overview implies
everything lives in one repo but the architecture needs a hub/worker
composition layer not in the graph, the gap gets filled with
'assembly layer' as an escape hatch. The overview is rewritten to
match the real boundary.

TLS spec review fixes (from architecture review):
- C3: hub/worker/hub-worker terminology pointers (tls README + endpoint.md)
- W1: server-only statement + OQ-64 (client-side TLS helper, deferred)
- W2: ACME task lifecycle semantics (returns immediately, no first-cert await)
- W3: remove stale EndpointError::TlsConfig variant
- W4: update stale ALPN section for two-config hub
- W5: add alknet-tls to hub dep graph (assembly-layer dep)
- W6: trim inline rationale -> point to ADR-084
- W7: ADR-084 status dependency note

New open questions:
- OQ-62: ALPN list sharing for two-config hub (open, high)
- OQ-63: TlsError shape (open, high)
- OQ-64: client-side TLS helper (deferred, blocked on OQ-55)

docs/architecture/crates/hub/README.md

@@ -564,7 +564,7 @@ fixed until the enrollment-token model is decided.
 ## Crate dependencies
 
 ```
-alknet-hub
+alknet-hub (Hub struct deps)
 ├── alknet-channels-call (ChannelClient, ChannelsAdapter, ChannelManager,
 │                         ChannelBidiStreamSource)
 ├── alknet-call (CallAdapter, Dispatcher, PeerCompositeEnv,
@@ -574,6 +574,12 @@ alknet-hub
 │                HandlerRegistry, AuthContext)
 ├── tokio (spawn, time::sleep)
 └── tracing (logging)
+
+  (assembly-layer deps — used by the hub's composition code, not by
+   the Hub struct itself)
+  ├── alknet-tls (TlsServerConfig — builds the raw-key + X.509/ACME
+  │               configs handed to the endpoint's transports)
+  └── alknet-core [tcp feature] (with_tcp_tls — the TCP+TLS accept loop)
 ```
 
 `alknet-hub` depends on `alknet-channels-call`, `alknet-call`, and
@@ -584,6 +590,15 @@ registration endpoint and browser HTTP access — the hub wires
 `HttpAdapter` into the same `HandlerRegistry` as
 `ChannelsAdapter`.
 
+`alknet-tls` is an **assembly-layer** dependency, not a `Hub` struct
+dependency: the `Hub` struct holds no `TlsServerConfig`, but the hub's
+composition code (the assembly-layer wiring shown in "Assembly layer
+integration" below) builds the `TlsServerConfig`s and hands them to the
+endpoint's transports via `for_quinn()` / `for_tcp_tls()`. This
+distinction matters: a consumer that uses `Hub` with externally-built
+transports does not pull `alknet-tls` through the `Hub` type, only
+through the assembly wiring.
+
 ## Assembly layer integration
 
 A downstream hub (alkapi) uses `alknet-hub` like this: