fifa17-recon: consumables CONFIRMED LIVE -- artwork, stacks and correct amounts

Rendering with real artwork, quantity badges and +5/+10/+15 amounts, so atom 0x1b
reaches record+0xbf. The client's own dialog names the class we resolved: 'Search
Type: Consumables Search'.

Records the three things that each had to be right and each failed silently with a
200: the count gates the fetch, the route is club/consumables/<category> (a /club
PREFIX, so it was being answered with the player list), and the element is a five-atom
stack wrapper whose 0x16a member is the only thing that carries the item.

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

fifa17-recon/docs/CARD_SYSTEM.md

@@ -331,3 +331,42 @@ A wrong manager carddbid is completely SILENT: FUN_1801356c0 has no else-branch
 writes no miss-fill, so a bad id and a bad wire shape look identical. The coaches were
 put on the same screen precisely because their miss IS loud. Nothing failed, but the
 test was designed so that a failure would have been diagnosable rather than mute.
+
+---
+
+# CONFIRMED LIVE 2026-08-05: consumables
+
+Rendering with real artwork, stack quantity badges and correct amounts (+5 / +10 /
++15, so atom 0x1b reaches record+0xbf and FUN_1801a8040's sign-extension never fires).
+The client's own dialog names the class: "Search Type: Consumables Search".
+
+## Three things had to be right, and each failed SILENTLY with a 200
+
+1. THE COUNT IS THE GATE. The client will not ask for consumable items until
+   GET club/stats/consumables reports a non-zero count. We answered that route 41
+   times a session with the PLAYER stat set, so the panel read seven zeros and never
+   proceeded. Two rounds of item-shape work sat unrequested for want of a counter.
+2. THE ROUTE IS GET club/consumables/<category>. Not club?type=, which a previous
+   round shipped four arms for, and not the "/consumables/%s" template in .rdata,
+   which the client has still never used. Worse, that path is a /club PREFIX, so it
+   fell through to the generic route and the consumables screen was answered with the
+   194-card player list.
+3. THE ELEMENT IS A STACK WRAPPER, NOT AN ITEM. FutConsumablesSearchServerResponse
+   (RS4 literal 0x1802222f8, factory 0x180130a10, vtable 0x180222200, deser +0x08 =
+   0x180130d10, 6873 chars) reads itemData(0x16b) at the root like the club list, but
+   its element is five atoms:
+       0xbc  count             0xd7  discardValue
+       0x16a item  -> FUN_18013fe00, the item parser itself
+       0x287 resourceId        0x362 untradeableCount
+   Everything else goes to the value-skip handler, so a bare item was ACCEPTED and did
+   nothing: the live card map held only the 11 squad players afterwards. That is also
+   why FUT draws consumables as one stack with a quantity rather than N cards.
+
+## The lesson, since it has now cost three rounds
+
+A 200 with a well-formed body that the consumer silently discards is the worst failure
+shape in this project. Nothing errors, nothing logs as unmapped, the screen is just
+empty. The diagnostic that worked every time was reading the CardsDb map: if the
+client ingested nothing, the shape is wrong; if it ingested records that do not draw,
+the failure is downstream. Guessing between those two costs a human a menu trip each
+time; the probe costs 0.03 seconds.