fifa17-recon: FUT squad blocker solved + userInfo delivered

The client now issues PUT /squad and the hub renders coins, record and the
squad roster. Three separate root causes, all verified live.

Squad blocker (the long-standing "client never sends PUT /squad"):
  AddPlayerToSquad, GetSquads and SelectSquadById issue ZERO network requests
  (pure local model reads/mutations, FutSquadServiceImpl vtable 0x180233ff0);
  only SaveCurrentSquad writes, and it is unguarded. The client simply needed a
  populated ACTIVE squad model, which arrives via the massinfo `squad` member.
  No response of ours was ever being rejected.

userMassInfo is NOT required to be {}:
  0x180174630 is a FLAT {userInfo, squad, settings, userData} body -- the old
  "wrapper key is user" note was wrong, and the historical freeze was the
  malformed squad member, not the envelope.

clubNameChangeAllowed must be false:
  sending true advertises a club-rename flow whose UI model is never populated;
  the client shows a naming prompt and dies confirming it (ACCESS_VIOLATION
  reading 0x0 at FIFA17.exe+0x71b8651, 4/4 runs, no CardsDLL frame and no request
  in flight). Isolated by a single-variable run; guarded by a contract check.

Endpoint/schema corrections found in live traffic, invisible to static analysis:
  * GET ut/%s/squad/list is a real endpoint and must return {"squad":[...]},
    not the active-squad object (the /list suffix is appended by the caller, so
    it never appeared in the request table)
  * PUT lands on ut/%s/squad/<id>, not a bare ut/%s/squad
  * userInfo currencies are read as name/funds/finalFunds/active -- there is no
    "value" key, so coins always rendered 0
  * squad-list elements take STRING formation/squadType, not ints
  * the CardsDLL script-API thunk<->name table was off by one (AddPlayerToSquad
    is 0x18004aa70; 0x18004aff0 is GetPotentialChemistry_Club)

FUT_MASSINFO / FUT_USERINFO ladders keep every step of the bisect reproducible.
Contract suite 311 -> 358 checks. Tooling added: PyGhidra harness (Ghidra's
Java/OSGi script path is broken on this box), minidump reader, live code grabber.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW

fifa17-recon/docs/ENDPOINT_MAP.md

@@ -78,8 +78,9 @@ minimal known-good JSON — including ack-only (`{}`) responses.
 - Store `extPrice` inner keys are **`amount`/`currency`**, not `mtx`; pack identity is
   **`assetId`** (0x23), not `id` (harmless SKIPs otherwise).
 - `ut/v2/store` must return `{"result":"SUCCESS"}` (currently unhandled → contributes to store error).
-- `GetUserMassInfo` top-level wrapper key is **`user`** (calls userInfo/squad/settings sub-parsers);
-  keep `{}` until every nested shape is exact (freeze-sensitive).
+- ~~`GetUserMassInfo` top-level wrapper key is **`user`**~~ — **WRONG, corrected 2026-08-03.**
+  The body is FLAT: `userInfo`(0x370)/`squad`(0x2cd)/`settings`(0x2bf)/`userData`(0x36d) are
+  top-level keys. `user`(0x36c) only appears nested inside `clubUser`. Now served populated.
 - No-op deserializers (bare `ret`) where `{}` always suffices: ChangeClubName, ActivateCard,
   SignLoanPlayer, and most ack responses.
 
@@ -1171,23 +1172,26 @@ reader → infinite spin at `0x1801c7f1a` (the hub freeze).
   `actives`[] (array).
 - **Handled:** `utas_server.USER_GET = {"userInfo": user_info()}`.
 
-### FutGetUserMassInfoServerResponse — CONFIDENCE: HIGH (freeze behavior) ⚠ MUST BE {} — GAP for populated
-- **Deser:** `0x180174630` (freeze-sensitive per CARD_SYSTEM.md).
+### FutGetUserMassInfoServerResponse — CONFIDENCE: HIGH (schema) ✅ SERVED POPULATED (live-verify)
+- **Deser:** `0x180174630` (full decompile: `/tmp/ghidra_fut/massinfo.txt`).
 - **HTTP:** `GET ut/%s/userMassInfo`
-- **Top-level keys (this deser dispatches):**
-  - `user` (0x36c) — nested → calls userInfo deser `0x18013ec10`
-    *(NOTE: the wrapping key is `user`, not `userInfo` — relevant if ever populated)*
-  - `clubUser` (0x91) — nested
-  - `settings` → calls settings deser `0x18013c6d0`
-  - squad → calls LoadActiveSquad deser `0x18013d1f0`
-  - `transaction` (0x339), `errors` (0x10c, array), `loanPlayers` (0x19a, array),
-    `pileSizeClientData` (0x227), `key`(0x177)/`value`(0x377) pairs
-- **CRITICAL:** any content (userInfo AND/OR squad) desyncs the massinfo parser →
-  infinite tokenizer spin (`0x1801c7f1a`). **Return `{}`** — proven hub-reaching.
-  The exact squad/squadList shape + the userInfo nested-object typing (feature /
-  unopenedPacks / currencies) is the open desync GAP; deliver club/squad via their
-  own endpoints instead.
-- **Handled:** `utas_server` `FUT_MASSINFO=empty` → `{}`.
+- **Shape: FLAT object, NO wrapper.** (Corrected 2026-08-03 — the earlier "wrapper key is
+  `user`" note was wrong; `user`(0x36c) occurs only nested inside `clubUser`. The prologue,
+  2×NextToken before the key loop, is identical to the proven-flat CreateUser parser
+  `0x18014cc60`.)
+- **Top-level keys this deser dispatches:**
+  - `userInfo` (0x370) → userInfo deser `0x18013ec10`
+  - `squad` (0x2cd) → LoadActiveSquad deser `0x18013d1f0` (loads the ACTIVE squad model)
+  - `settings` (0x2bf) → settings deser `0x18013c6d0`
+  - `userData` (0x36d) → `0x180142470`
+  - `clubUser` (0x91), `errors` (0x10c), `loanPlayerClientData` (0x199),
+    `loanPlayers` (0x19a), `pileSizeClientData` (0x227)
+  - everything else → SKIP (`0x180135ff0`)
+- **Freeze history:** the documented "any content desyncs" was recorded before the squad
+  schema was reversed; the prime suspect is the malformed `squad` member fed to
+  `0x18013d1f0`. Every `user_info()` field type-checks against `0x18013ec10`.
+- **Handled:** `utas_server.massinfo()` → `{userInfo, squad, settings, userData}`;
+  `FUT_MASSINFO=full|squad|userinfo|settings|empty` bisects it one member per relaunch.
 
 ### FutGetSettingsServerResponse — CONFIDENCE: HIGH ✅ HANDLED
 - **Deser:** `0x18013c6d0`