docs(fifa17): a LeagueName_Abbr_15 path exists — recorded as a lead, not a fix

FUN_180098f20, previously described as the league-logo function with a hedged
"localizedName, probably", read in full: it queries fcc_leaguelogos WHERE
leagueid == %d, reads carddbid/value/cardassetid, and captions with
'LeagueName_Abbr_15_%d' in the 'FUT String' domain. A database-backed league
name therefore exists, in exactly the shape kits use for teamid — so "cardtype 9
has no DB name resolver" is too strong for league logos.

Deliberately NOT concluded: its only caller passes [rbx+0x20] as the league id,
and rbx there is a loop cursor over small list elements (int/double/int), not the
0x158-byte card record. Reading that as the record's assetId and shipping "send
leagueid as assetId" would be the exact inference this document exists to
prevent. Recorded as a lead with the next question named: does the OWNED render
path reach this resolver, and which field feeds it?

fifa17-recon/docs/plan-2026-08-06-card-subsystem.md

@@ -431,6 +431,39 @@ nothing else. Ownership, `content_kind`, club/stats counting and restart
 durability are already in place for all three, so the probe is the only
 remaining work: the projection arm is a two-line change once the name is proven.
 
+#### A lead on league logos: a `LeagueName_Abbr_15_%d` path DOES exist
+
+`FUN_180098f20` (named above as the league-logo function, hedged "localizedName,
+probably") was read in full on 2026-08-21. It builds a real database query, and
+the literals settle what it does:
+
+```
+table     'fcc_leaguelogos'
+where     'leagueid' '==' %d          ; the id arrives in r9d
+columns   'carddbid'  'value'  'cardassetid'
+caption   'LeagueName_Abbr_15_%d'     ; a localisation key built from the league id
+domain    'FUT String'
+```
+
+So a database-backed league NAME demonstrably exists in the client, keyed on
+`leagueid`, in exactly the shape kits use (`TeamName_Abbr15_<teamid>`). That
+makes the blanket claim "cardtype 9 has no DB name resolver" too strong for
+league logos specifically.
+
+WHAT THIS DOES NOT YET SHOW, stated plainly because the obvious next step is a
+trap. Its ONLY caller is `0x180098da3`, and the `[rbx+0x20]` it passes as the
+league id is NOT the item record: `rbx` is reloaded from `[rsp+0x48]` and
+compared against an end pointer, i.e. it is a cursor over a list of small
+elements (int at `+0x20`, double at `+0x24`, int at `+0x2c`), not the 0x158-byte
+card record. So this is a CATALOG/BROWSE builder, and it is not established that
+the owned-item render path reaches it at all. Reading `+0x20` as the record's
+`assetId` and concluding "send the leagueid as assetId" would be exactly the
+kind of inference this document exists to prevent.
+
+The lead worth following: find whether the owned cardtype-9 render path reaches
+this resolver, and if so which field feeds the league id. If it does, league
+logos need no `localizedName` at all and separate from the ball/misc gap.
+
 ---
 
 ## 4. The card lifecycle