docs: OQ-SK-04 restructured as the conditional decision tree it is

The root question is 'does wasm make sense for alksocks?', not 'how
do we get wasm': Case 1 (wasm wanted) -> fork-first, PR as courtesy,
carry regardless; Case 2 (wasm unwanted) -> plain dependency on the
router.rs native path, no fork (the alkhttp precedent, strictly
better when its premise holds). Decision inputs written: (a) is
there a planned sandboxed (wasm) consumer of the SOCKS5 service,
(b) is the fork genuinely minimal (POC #4 checks). Fork-first is a
conditional preference, not a general one — do not carry a fork for
an invariant's sake. AGENTS.md conventions 4/17 aligned.

AGENTS.md

@@ -90,11 +90,13 @@ implementation agents.
    (`rt`, `sync`, `io-util`, `macros`, `time`) — **do NOT use `features
    = ["full"]`** — and keep socket/platform I/O feature-gated. Note:
    `fast-socks5` itself uses `tokio::net` and `socket2` unconditionally;
-   the resolved posture (OQ-SK-04) is fork-first: vendor the needed
-   subset and feature-gate native-net pieces (the alkhttp crate shows a
-   native-only crate is possible, but wasm-clean remains the preferred
-   posture here). Run the wasm check whenever a non-backend module
-   changes.
+   the posture is conditional (OQ-SK-04): if wasm matters for this
+   crate, the path is fork-first (vendor the `T`-generic subset, gate
+   native-net pieces — see OQ-SK-04 Case 1); if wasm does not matter,
+   ride the native `router.rs` path with a plain dependency (Case 2 —
+   the alkhttp precedent). The root question — does wasm make sense
+   here — is the OQ to settle; do not carry a fork for an invariant's
+   sake. Run the wasm check whenever a non-backend module changes.
 
 5. **Wire format is stable** — the SOCKS5 protocol itself is RFC 1928
    (fixed); this crate's wire surface is the ALPN + the channel open-op
@@ -227,13 +229,14 @@ implementation agents.
     One ALPN per protocol. The ALPN string is wire-stable once
     published — decide via ADR before the first consumer.
 
-17. **Upstream is ours — fork-first, PR as courtesy.** We own
-    `fast-socks5` (`/workspace/fast-socks5`, v1.0.0, MIT) and alkcall.
-    For changes this crate needs upstream, the preferred posture is:
-    make the change as a minimal fork and use it — offer it upstream
-    as a PR and merge upstream if they want it, but never wait on
-    approval (see `docs/research/phase-0.md` OQ-SK-04's resolved
-    posture). For alkcall (the actively co-developed substrate) the
+17. **Upstream is ours — fork-first where it pays, asks for alkcall.**
+    We own `fast-socks5` (`/workspace/fast-socks5`, v1.0.0, MIT) and
+    alkcall. For fast-socks5, the posture is conditional (OQ-SK-04):
+    if wasm matters for this crate (Case 1), make the change as a
+    minimal fork and use it — offer it upstream as a PR and merge
+    upstream if they want it, but never wait on approval; if wasm does
+    not matter (Case 2), ride the native path with a plain dependency,
+    no fork. For alkcall (the actively co-developed substrate) the
     alk* precedent still applies: file asks early and land them there
     rather than working around them locally — the alktunnels precedent
     (the E-01/E-02 sweep, filed from its Phase 0 and landed in alkcall