fifa17-recon: club-item research -- cardtype map exact, itemState carries equipped state

Researched rather than guessed, after a guessed field crashed the client.

VERIFIED: FUN_1800d8330 returns cardtype 9 for exactly 0x1e, 0x1f, 0x91..0x96,
0xe7..0xe9, 0xec; fcc_misccards' cardsubtype 231 anchors the 0xe7 block to misc, so
badges/kits/stadia/balls/logos live in 0x1e, 0x1f and 0x91..0x96.

VERIFIED, and it answers a question nobody had asked: the itemState enum at
0x180229d20 is WAITING_FOR_GAME, inGame, forSale, offered, activeBadge, activeHomeKit,
activeAwayKit, activeBall, activeStadium, active. An EQUIPPED club item is the same
item with itemState set, not a different subtype. 'free' is right for owned-but-not-
equipped, which is what we already send.

VERIFIED: club items have no category group table (consumables and staff both do), and
the route is club?type= with SINGULAR names, observed live.

STILL UNKNOWN and labelled so: which subtype means which family. Not in any of the 149
dumped tables, no group table, and cardtype 9 has no merge arm so a wrong value cannot
announce itself.

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

fifa17-recon/docs/CARD_SYSTEM.md

@@ -397,3 +397,53 @@ THE TRAP GENERALISES. An fcc_ row carries BOTH carddbid and cardassetid and they
 not interchangeable. fut_store._item copies resourceId into cardassetid, which is
 correct for players and wrong for every other family. The club-item family will need
 the same mapping: balls 37, kits 35, stadium 36, badges 39, league logos 40.
+
+---
+
+# Club items: what the research established, 2026-08-05
+
+Researched after a guessed field crashed the client. Facts first, and the one thing
+still unknown is named as unknown.
+
+## VERIFIED IN BINARY
+
+1. THE CARDTYPE MAP IS EXACT. FUN_1800d8330 (714 chars, read in full) returns cardtype
+   9 for cardsubtypeid 0x1e, 0x1f, 0x91..0x96, 0xe7..0xe9 and 0xec, and nothing else.
+   fcc_misccards carries cardsubtype 231 = 0xe7, which anchors the 0xe7..0xe9 block to
+   misc cards. That leaves 0x1e, 0x1f and 0x91..0x96 for badges, kits, stadia, balls
+   and league logos.
+2. ITEMSTATE CARRIES THE EQUIPPED STATE. The enum table at 0x180229d20 (stride 0x10)
+   is: WAITING_FOR_GAME, inGame, forSale, offered, activeBadge, activeHomeKit,
+   activeAwayKit, activeBall, activeStadium, active. So an EQUIPPED club item is not a
+   different subtype, it is the same item with itemState set to one of those five.
+   "free" is correct for owned-but-not-equipped, which is what we send.
+3. CLUB ITEMS HAVE NO CATEGORY GROUP TABLE. Consumables have one at 0x180203260 (seven
+   codes: training, contracts, fitness, healing, playStyle, managerLeagueModifier,
+   position) and staff have one at 0x180203310 (five codes). There is no equivalent
+   for club items; the only club-item strings are the COUNT labels
+   FUT_MYCLUB_KITS_AVAILABLE / BADGES_AVAILABLE / STADIA_OWNED / BALLS_EARNED, which
+   we already serve correctly.
+4. THE ROUTE IS club?type= WITH SINGULAR NAMES. Observed live: type=stadium,
+   type=ball, type=equippables (the combined customisation view). Not the plural stat
+   names, and not a club/<family> path.
+
+## STILL UNKNOWN, AND NOT GUESSED
+
+Which of 0x1e, 0x1f, 0x91..0x96 means ball versus stadium versus badge versus kit.
+It is in none of the 149 dumped tables, there is no group table, and cardtype 9 has NO
+arm in the merge, so a wrong subtype cannot announce itself the way a coach's "DB
+Error" does. Two ways to settle it, in order of preference:
+  a. more RE: find the consumer that switches on subtype for a club item, most likely
+     in the equip path that writes itemState = activeBadge and friends;
+  b. FUT_CLUBITEMS=probe:<family>, which serves ONE family as eight items, one per
+     candidate subtype, so the screen names the right one.
+
+## WHY THE CRASH HAPPENED, recorded so it is not repeated
+
+teamid, leagueid and value were copied out of the fcc row as "extras". `value` appears
+elsewhere as an OBJECT member (displayGroup {"value": ...}); a scalar where an object
+is expected is the type-desync busy loop at 0x1801c7f1a, which presents as the game
+taking its time and then dies. None of the three was needed to draw a card. Compounding
+it, the response that crashed was type=equippables carrying 30 items across FIVE
+unverified subtypes at once, so even the crash taught us nothing about which subtype
+was wrong. Both are fixed: no extras, equippables withheld, one family per test.