TASK-033-004: Update ARCHITECTURE.md — Protocol Engine Core section

Updated the Protocol Engine Core section to document the actual implementation:
- Replaced description of four per-version GroupByRequestKey instances with single shared GroupByRequestKey
- Clarified maxSubstreams as a single shared ceiling (not per-version), configurable via TurboClientOptions.MaxEndpointSubstreams (default 256)
- Preserved note about async boundary between feature chain and engine core
- Updated topology diagram to show Partition(version) inside per-endpoint substreams, not as initial stage

Author: st0o0

.maggus/features/feature_033.md .maggus/features/feature_033_completed.md.maggus/features/feature_033.md renamed to .maggus/features/feature_033_completed.md

@@ -114,7 +114,7 @@ This feature inverts the topology: group by endpoint once at the top level, then
 **Model:** haiku
 
 **Acceptance Criteria:**
-- [ ] The **Protocol Engine Core** section in `ARCHITECTURE.md` is updated to show the new topology:
+- [x] The **Protocol Engine Core** section in `ARCHITECTURE.md` is updated to show the new topology:
   ```
   RequestEnricherStage
       → GroupByRequestKey(RequestEndpoint, max=MaxEndpointSubstreams)
@@ -123,10 +123,10 @@ This feature inverts the topology: group by endpoint once at the top level, then
               → Merge(4)
       → MergeSubstreams
   ```
-- [ ] The old description of four per-version `GroupByRequestKey` instances is removed
-- [ ] `maxSubstreams` note is updated: single shared ceiling, configurable via `TurboClientOptions.MaxEndpointSubstreams`, default 256
-- [ ] The note "An async boundary separates the feature chain from the engine core" is preserved if still accurate
-- [ ] No other sections of `ARCHITECTURE.md` are modified
+- [x] The old description of four per-version `GroupByRequestKey` instances is removed
+- [x] `maxSubstreams` note is updated: single shared ceiling, configurable via `TurboClientOptions.MaxEndpointSubstreams`, default 256
+- [x] The note "An async boundary separates the feature chain from the engine core" is preserved if still accurate
+- [x] No other sections of `ARCHITECTURE.md` are modified
 
 ---
 

ARCHITECTURE.md

@@ -96,20 +96,19 @@ Request flows top-to-bottom; response flows bottom-to-top. Only BidiFlows for no
 
 ### Protocol Engine Core
 
-`ProtocolCoreGraphBuilder` wires the engine graph:
+The protocol engine core routes requests by endpoint and version, then wires them through version-specific connection flows:
 
 ```
 RequestEnricherStage
-    → Partition(version)   [Out0: 1.0 | Out1: 1.1 | Out2: 2.0 | Out3: 3.0]
-    → GroupByHostKey(RequestEndpoint)
-        → per-host substream: ExtractOptions → Engine BidiFlow ↔ ConnectionStage
-                                            → ConnectionReuseFlowStage
+    → GroupByRequestKey(RequestEndpoint)   [per-endpoint substream]
+        → per-endpoint substream: Partition(version) [Out0: 1.0 | Out1: 1.1 | Out2: 2.0 | Out3: 3.0]
+            → [H10|H11|H20|H30] engines ↔ ConnectionStage ↔ ConnectionReuseStage
+            → Merge(4)
     → MergeSubstreams
-    → Merge(4)
 ```
 
 - `RequestEndpoint` key = `(Scheme, Host, Port, Version)` — case-insensitive.
-- `maxSubstreams`: HTTP/1.x → 256, HTTP/2/3 → 64.
+- `maxSubstreams`: Single shared ceiling per endpoint, configurable via `TurboClientOptions.MaxEndpointSubstreams`. Default is 256.
 - An async boundary separates the feature chain from the engine core (protocol work runs on its own dispatcher).
 
 ### Per-Version Engine Assembly