docs: mapping synthesis — online-activation gate + tooling limit

Full gate map: LSX bootstrap DONE; EbisuSDK online report DONE at SDK level
(events parse, listener no-op); EASFC subsystem DORMANT (built at boot, never
activated); GetAuthCode/Blaze never reached. The missing link is runtime
'go online' activation between the SDK online-report and the EASFC subsystem.
No single activation flag isolable via byte-scan — the subsystem is pervasive
(GetConnState has 61 callers), consistent with online-mode being a whole
subsystem activation, not a switch. Next tool: Ghidra/IDA or continued dynamic
probing. Confirms the M2 frontier with pre-Blaze infra present.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/connection-gate-findings.md

@@ -967,3 +967,42 @@ FIFA to the *next* wall — dialing the Blaze redirector (gosredirector) and spe
 is the full multi-month M2→M6 Blaze-emulation frontier. This run empirically confirms we are
 standing exactly at the M2 boundary the status review priced, with the pre-Blaze infrastructure
 proven present. Decision point vs [[project_direction_pivot]] (FLE career = stated primary plan).
+
+---
+
+## MAPPING SYNTHESIS — the online-activation gate, and a tooling limit (2026-07-02)
+
+Goal after run 4: map the exact trigger that would wake the dormant EASFC subsystem.
+Result: the gate is characterized precisely at the subsystem level, but the *single*
+activation predicate could not be isolated with byte-level tooling — because the online
+subsystem is pervasive, not gated by one flag. That pervasiveness is itself the finding.
+
+**The complete gate map (proven, top to bottom):**
+1. LSX bootstrap — DONE. FIFA reaches "connecting to EA Servers" cleanly; bridge answers
+   GetConfig/GetProfile/GetGameInfo/GetSetting/GetInternetConnectedState/etc.
+2. EbisuSDK online report — DONE at the SDK level. Our OnlineStatus/Login event pushes parse
+   (deserializers fire) and set FIFA's stored online bool (HandleMessage map store). BUT the
+   game-side listener is a no-op (dispatch → +0x2751060 = `ret 0`): no active handler reacts.
+3. EASFC/Nucleus online-connect subsystem — **DORMANT.** Its connect-state array is built at
+   boot (ctor fires 4x) as part of OriginSDK init, then never touched (GetConnState 0x, no
+   vtable step fires). Session context [M+0x778] exists. nucleusConnectREST/GetAuthCode never
+   fire because nothing iterates/activates the subsystem.
+4. GetAuthCode → Nucleus token → Blaze redirector → Fire2 — NEVER REACHED (the M2→M6 frontier).
+
+**The missing link = runtime "go online" activation** between (2) and (3): the thing that, on
+"online", makes FIFA's online controller start iterating/driving the connect states. anadius
+(offline DRM) never drives it; our LSX bridge reaches the SDK layer (2) but not the game's
+top-level online-mode activation (3). Attempts to isolate a single activation flag via static
+byte-scan failed: GetConnState has 61 callers, the connect-state getter family and the online
+globals resolve to hundreds of sites — the subsystem is woven throughout, so there is likely no
+one boolean to flip. This is consistent with FIFA being a full online client whose online mode
+is an entire subsystem activation, not a switch.
+
+**Tooling note for whoever continues:** byte-level objdump + offset scans were enough to
+CHARACTERIZE the gate (this whole document) but are the wrong tool to find the activation
+predicate inside a 500 MB pervasive subsystem. The right next tool is a decompiler (Ghidra/IDA)
+to recover FIFA's online-controller Update and its guard as structured code, or continued
+dynamic probing (the openfut-hook `probe` framework — 8 entry detours + a VirtualQuery-guarded
+memory sampler — is reusable) to watch the controller Update's guard value live. Either way this
+is confirmed to be the multi-month M2 frontier; pre-Blaze infrastructure is proven present, and
+FIFA sits one activation away from the first Blaze dial. Weigh against [[project_direction_pivot]].