docs(arch): endpoint types and entry points (ADR-086) — resolves OQ-62

Name the three-endpoint-type model (web/native/iroh) and the
entry-point vs. endpoint ALPN distinction. This untangles the
hub/endpoint/ALPN-config confusion that OQ-62 hinted at:

- A hub composes a SUBSET of three endpoint types (web, native, iroh),
  each with its own identity model, auth model, and transport(s). A
  full hub runs all three; a minimal hub runs iroh alone (no public
  IP required). The first real use case is web + native. Corrects the
  hub README's 'must support TCP+TLS and QUIC' framing.

- ALPNs split into entry points (accepted without identity — h2,
  http/1.1, future alknet/register) and endpoints (identity required
  before dispatch — alknet/channels, alknet/call, alknet/ssh). This
  resolves OQ-62: split ALPN lists by endpoint type (Option B), because
  each endpoint type serves a different client class with different
  negotiable ALPNs. The assembly-layer wiring pattern is now guessable.

- Foundational handlers are two categories, not one: channels
  data-channel ALPNs (tunnel, socks5, fs, sftp — gated by channels,
  not in any TLS ALPN list) vs. SSH (an endpoint ALPN that wraps
  channels inside it, RFC 7250 keys, legacy compat, comes later).

Files OQ-65 (WebSocket carrying channels — the browser story update)
filed as a one-way-door question, open. ADR-048 is not superseded;
OQ-65 may extend it. The web config advertises alknet/channels by
default so the hub is ready if OQ-65 resolves to 'WebSocket carries
channels.'

docs/architecture/questions/062-alpn-list-sharing-two-config-hub.md

@@ -7,7 +7,7 @@
   lists); `docs/architecture/crates/core/endpoint.md` (the ALPN section
   previously stated "both connection sources advertise the same set of
   ALPNs," which is stale under the two-config hub model).
-- **Status**: open
+- **Status**: resolved
 - **Door type**: one-way (the ALPN list each `TlsServerConfig` advertises
   is baked into the `rustls::ServerConfig` at construction; changing it
   after the hub is deployed is a config+restart, but the *pattern* —
@@ -16,39 +16,51 @@
 - **Priority**: high (the hub is the first two-config consumer; its
   wiring sets the pattern, and an implementer cannot write the hub's
   assembly code without this decided)
-- **Resolution**: Not yet decided. The two plausible options:
+- **Resolution**: **Split list, by endpoint type.** Each
+  `TlsServerConfig` advertises only the ALPNs its endpoint type's
+  client class can negotiate. The hub composes a subset of three
+  endpoint types (web, native, iroh), each with its own identity model,
+  auth model, and transport(s). The assembly layer filters
+  `registry.alpn_strings()` per `TlsServerConfig` by endpoint type:
 
-  **Option A — same list (union) to both configs.** Both
-  `TlsServerConfig`s receive `registry.alpn_strings()` verbatim. The
-  raw-key QUIC listener advertises `h2`/`http/1.1` (browsers can't
-  connect to a raw-key listener anyway, so the advertisement is
-  harmless dead negotiation). The X.509 TCP+TLS listener advertises
-  `alknet/call` (a native client connecting over TCP+TLS with an X.509
-  client cert can use it). Simplest wiring; no split logic; every
-  transport can serve every ALPN.
+  - **raw-key config (native endpoint)**: `alknet/channels`,
+    `alknet/call`, `alknet/ssh` (future) — the native ALPNs. No
+    `h2`/`http/1.1` (browsers cannot connect to a raw-key listener;
+    native clients do not negotiate HTTP ALPNs).
+  - **X.509/ACME config (web endpoint)**: `h2`, `http/1.1`,
+    `alknet/channels` (for WebSocket-carrying-channels, per OQ-65),
+    `acme-tls/1` (appended automatically). No `alknet/call` as a
+    top-level ALPN unless the deployment explicitly serves
+    call-over-TCP on the web endpoint.
+  - **iroh builder (iroh endpoint)**: `alknet/channels`,
+    `alknet/call` — iroh uses raw keys only; native ALPNs.
 
-  **Option B — split list, transport-appropriate.** The raw-key config
-  gets the native ALPNs (`alknet/call`, `alknet/channels`,
-  `alknet/tty`); the X.509/ACME config gets the union including
-  `h2`/`http/1.1` (browser ALPNs that only make sense over TCP+TLS with
-  a domain cert). The assembly layer filters `registry.alpn_strings()`
-  by which transports can serve each ALPN. More logic; cleaner
-  advertisement (no browser ALPNs on a raw-key listener).
+  The rationale: each endpoint type serves a different client class.
+  Advertising ALPNs the client class cannot negotiate (e.g., `h2` on a
+  raw-key listener) is harmless but misleading — it implies the
+  listener serves a client class it cannot. The split makes the
+  advertisement honest and the assembly-layer wiring pattern guessable.
 
-  The question is whether the "harmless dead negotiation" in Option A
-  is acceptable or whether the cleaner advertisement in Option B is
-  worth the split logic. This needs a decision before the hub's
-  assembly code is written — it is not guessable from the existing
-  specs, and guessing produces a wiring shape that downstream consumers
-  copy.
+  The naming that makes this answerable is the **entry-point vs.
+  endpoint** distinction (ADR-086 §2): entry-point ALPNs (`h2`,
+  `http/1.1`, future `alknet/register`) are accepted without
+  established peer identity (per-request auth); endpoint ALPNs
+  (`alknet/channels`, `alknet/call`, `alknet/ssh`) require identity
+  resolution. The web config advertises entry-point ALPNs (for
+  registration, browsers) + `alknet/channels` (for
+  WebSocket-channels); the native config advertises endpoint ALPNs
+  (for native clients); iroh advertises endpoint ALPNs (for p2p
+  peers).
 
-  Note: this is distinct from the *iroh* path. Iroh takes its ALPN list
-  from `iroh::Endpoint::builder().alpns()` at construction, set by the
-  assembly layer from `registry.alpn_strings()`. Iroh uses raw keys
-  only, so it gets the native ALPN set regardless of which option is
-  chosen for the quinn/TCP+TLS pair.
-- **Cross-references**: ADR-082 (`TlsServerConfig::new` takes
-  `alpns: &[Vec<u8>]` — the caller decides), ADR-083 (the assembly
-  layer builds transports; ALPN-list construction is its job),
-  OQ-64 (client-side TLS helper — related but orthogonal; this OQ is
-  server-side advertisement)
+  See [ADR-086](../decisions/086-endpoint-types-and-entry-points.md)
+  for the full decision, including the three-endpoint-type model, the
+  hub-shape table (full / web+native / native+iroh / minimal), and the
+  foundational-handler categorization (channels data-channel ALPNs vs.
+  SSH as an endpoint ALPN that wraps channels).
+- **Cross-references**: [ADR-086](../decisions/086-endpoint-types-and-entry-points.md)
+  (the decision), ADR-082 (`TlsServerConfig::new` takes
+  `alpns: &[Vec<u8>]` — the caller decides; this OQ specified how),
+  ADR-083 (the assembly layer builds transports; ALPN-list construction
+  is its job), OQ-65 (WebSocket carrying channels — why the web config
+  advertises `alknet/channels`), OQ-64 (client-side TLS helper —
+  related but orthogonal; this OQ is server-side advertisement)