docs: OQ-SK-02 direction settled — "both" auth, split by the door

- endgame story makes both mechanisms real: consumer binds the produced
  SOCKS5 resource locally (optional front door, ssh -D shape without
  the forced bind) and points tun2proxy at it
- producer side: identity seam only (CF-005/CF-006); a password there
  is moot against the ACL system — in-band conversation runs NoAuth
- consumer front door: owns RFC 1929 where vanilla clients need it
  (tun2proxy/curl user:pass), maps accepted credentials to the channel
  identity it opens the producer with; the SOCKS password never crosses
  the channel as a SOCKS password
- replace-or-second-gate sub-question dissolves: the mechanisms occupy
  different planes (door-local creds vs channel-level identity)
- remaining for Phase 1: credential->identity mapping shape; producer-
  side local backend door surface; AuthMethod trait vs door-owned check

docs/research/phase-0.md

@@ -388,10 +388,52 @@ own optional username/password auth (RFC 1929). Questions:
   consults the alkcall `AuthContext`/`Identity` (filed upstream if the
   hook shape doesn't fit — AGENTS.md convention 17)?
 
-Hunch: identity-at-the-open-op is the primary gate for
-channels-native consumers; in-band username/password exists for the
-local-backend path only. Needs a decision (and possibly an upstream
-ask) in Phase 1.
+(Answered in direction by the 2026-09-13 posture statement below:
+yes / planes-don't-compare / probably-not — Phase 1 formalizes.)
+
+**Posture — settled direction (2026-09-13 discussion): "both," split
+by the door.** The planned end-to-end story is the vpn-like
+composition: a consumer connects to an endpoint producing the SOCKS5
+resource, *optionally* binds it locally (component 2's front door —
+ssh `-D`'s shape, with the defining difference that no port is bound by
+default), and points tun2proxy (`--proxy socks5://user:pass@host:port`
+natively, per §Vision principle 6) at the local port. That makes "both"
+auth mechanisms real, each on its own side of the door:
+
+- **Producer side: identity only.** The channels-native open is
+  authorized by the alkcall ACL/identity seam (CF-005/CF-006); a
+  producer-side password is moot — the ACL system is strictly better
+  than a shared secret, and the producer's in-band conversation runs
+  NoAuth/no-op. A password there would add nothing the identity seam
+  doesn't already do.
+- **Consumer side (the front door): RFC 1929 where vanilla clients
+  need it.** The door is where the vanilla world meets the ACL world,
+  so it owns credential presentation: a vanilla client carrying
+  `user:pass` (tun2proxy, curl) gets a real RFC 1929 conversation at
+  the door. The door then maps the accepted credential to *local*
+  configuration — which channel identity/endpoint to open the producer
+  channel with — and that identity reaches the producer via the
+  CF-005/CF-006 seam. The SOCKS password never crosses the channel as
+  a SOCKS password; the channel identity never reaches the vanilla
+  client.
+
+The "replace or second-gate" sub-question dissolves: the mechanisms
+occupy different planes (in-band creds are door-local; identity is
+channel-level). The NoAuth door (POC #1's raw-pipe shape, zero
+protocol translation) remains valid for loopback-only or wrapper-aware
+use; the cred-bearing door is the same bridge plus the greeting half
+(fast-socks5's server typestate for auth + `read_command`, then the
+consumer session in-band) — an assembly-layer choice, not a protocol
+one.
+
+Remaining for Phase 1: the door's credential→identity mapping shape
+(static config vs pluggable lookup); whether the producer-side
+optional local backend offers the same door surface (same code shape —
+door = vanilla↔ACL boundary — so presumably yes); and whether the door
+needs a fast-socks5 `AuthMethod` impl or simply checks credentials
+itself before handing the stream to the typestate (likely the latter —
+the door is this crate's code, the trait was designed for embedders
+who don't own the accept loop).
 
 ### OQ-SK-03: UDP ASSOCIATE without binding — the hard case
 
@@ -824,7 +866,12 @@ Candidate reading for the research specialist (to be expanded):
       primary, in-band auth for the local backend); **POC #1 validated
       the seam end to end** (per-call opener identity at the
       establisher; channel-0 identity propagation is a producer
-      harness wiring requirement); decide in Phase 1
+      harness wiring requirement); **direction settled 2026-09-13**
+      ("both," split by the door: producer-side identity only — a
+      password there is moot against the ACL; consumer-side front door
+      owns RFC 1929 for vanilla clients and maps credentials to the
+      channel identity); Phase 1 formalizes the door's
+      credential→identity mapping
 - [ ] OQ-SK-03 (UDP ASSOCIATE) — the shape space written (including
       the phase-model-vs-alktty-demux analysis); resolve via research
       + POC #2, ADR before the first consumer