docs(fifa17): apply the plan's corrections to CARD_SYSTEM.md and fut_store.py

Section 7 of plan-2026-08-06-card-subsystem.md listed these and they were never
applied, so the stale text kept misleading readers — it already cost this project
a ten-row itemState table.

CARD_SYSTEM.md:
  - "STILL UNKNOWN, AND NOT GUESSED" is ANSWERED. Its candidate set was wrong:
    it asked which of 0x1e/0x1f/0x91..0x96 meant kit/badge/stadium, but three of
    the five families are cardtype 7 (kit 9, stadium 10, badge 11) and are not in
    that set at all, and 0x91..0x96 are trophies. Replaced with the settled map
    and how each family's caption resolves.
  - itemState table starts at 0x180229cc0, not 0x180229d20 — the recorded address
    points MID-table, which is why six rows were missing. Added that
    WAITING_FOR_GAME/inGame are aliases, that omitting the key yields invalid and
    not free, and that the match is case-sensitive (measured).
  - the consumables route claim "the /consumables/%s template ... the client has
    still never used" is false; it IS that template, with base index 3 = ut/%s/club.
  - added the dated field-map correction block, extended with the +0x60 and
    definitionId findings measured on 2026-08-21.

tools/fut_store.py: the discard_value premise "that lookup returns no row for our
cards" / "WHY its lookup misses is still UNKNOWN" is false — it does not miss, the
tile reads a different property. That story sent one round of work chasing a table
defect that never existed.

fifa17-recon/tools/fut_store.py

@@ -299,10 +299,16 @@ def player_item(item_id, player, special=False):
 # The cause is the guard the table work reversed. FUN_18013fe00 stores our
 # discardValue at item +0x38; at 0x180141025 a `cmp dword [rbp+0x198],0` / `ja` skips
 # the client's own local computation when that value is NON-ZERO. We seed 0, so the
-# client runs its own fcc_discardcoins lookup, that lookup returns no row for our
-# cards, the price register stays 0, and it renders 0. WHY its lookup misses is still
-# UNKNOWN and worth knowing, but it does not have to be answered to fix the display:
-# sending a non-zero value bypasses the lookup entirely and the client uses ours.
+# client runs its own fcc_discardcoins lookup and the price register stays 0.
+#
+# CORRECTED 2026-08-06: the two claims that used to sit here -- "that lookup
+# returns no row for our cards" and "WHY its lookup misses is still UNKNOWN" --
+# are both FALSE. The lookup does not miss; real rows exist for both rare values
+# on (cardtype 6, level, rare). The tile reads a DIFFERENT property, which is why
+# the wallet and the screen disagreed. Sending a non-zero value still fixes the
+# display, for the reason below -- it bypasses the local computation entirely --
+# but do not carry the "missing row" story forward: it sent one round of work
+# looking for a table defect that was never there.
 #
 # Freeze risk: low and in the safe direction. discardValue is a plain INT read by the
 # scalar getter 0x1801c79d0. The freezes on this project have all come from feeding an