docs(re): refute the contract:7 effect source; record the competing development reading

Two corrections found while trying to close the effect boundary statically.

1. `contract: 7` IS OUR OWN PLACEHOLDER. fut_store.py:232's generic _item()
   factory -- which builds every item the oracle serves -- hardcodes
   playStyle 250 / contract 7 / fitness 99 on players and consumables alike. The
   staging GK reads back exactly those three constants. So the production
   catalog's contract:7 for resource 5001004 is an oracle placeholder
   round-tripped through an observed profile, not an EA value. Its status is not
   INFERRED, it is KNOWN-BOGUS as a source. Had the effect been implemented on
   it, it would have been a fabricated game rule wearing observed-data clothing.

2. fcc_contractcards is NOT amount-less. An earlier note here claimed it "has no
   amount column, so this value comes from observed data". It has 13 rows with
   gold/silver/bronze/rating, 6 player + 6 manager paired by rating plus a
   99/99/99 special. The sibling fcc_healingcards shares every column except
   that it carries a single `amount`, which argues the differing columns ARE the
   effect payload (per target tier). Against that: the values are non-monotonic
   across tiers, which suits weights better than amounts; and no column of
   5001004 is 7, so neither reading explains the placeholder.

   The reader that would settle amount-vs-weight is in FIFA17.exe, not CardsDLL
   (the table and column literals are absent from the DLL), so this stays
   EFFECT_UNKNOWN rather than being guessed.

Also records, in content_taxonomy.rs, the competing reading of `development`:
fut_consumables.py's TYPE_CATEGORIES groups it as card-categories {6,7,8,9,10}
(modifiers only), explicitly flagged there as inferred from UI-bucket names and
never observed on the wire. Different enum space from the CONSUMABLE_TYPE switch
that actually emits the segment, and the switch gives formation/position/
playStyle/managerLeagueModifier their own segments rather than folding them into
development -- so the unfiltered reading is better supported, but it is still a
reading and the doc now says so instead of sounding settled.

248 adapter tests, fmt clean. No behaviour change.

openfut-adapter-fifa17/src/fut/content_taxonomy.rs

@@ -247,6 +247,23 @@ pub fn consumable_needs(family: &str) -> ConsumableNeeds {
 /// and maps to every family — which is consistent, since the eight TYPED
 /// segments already reach all thirteen families exactly once.
 ///
+/// COMPETING INFERENCE, recorded rather than buried. `fut_consumables.py`'s
+/// `TYPE_CATEGORIES` maps `development` to card-categories `{6,7,8,9,10}`
+/// (formation/position/playstyle/manager-league) — i.e. the modifier families
+/// only, not everything. That grouping is explicitly flagged there as INFERRED
+/// from `FUN_180048780`'s UI-bucket names, with "the tab-to-arm binding has
+/// NEVER been observed on the wire".
+///
+/// They are not the same enum: the oracle's is the 0..10 CARD-category space of
+/// `FUN_18013f4d0`, this is the 0..24 CONSUMABLE_TYPE space that actually
+/// produces the URL segment. The tiebreaker is the switch itself — it gives
+/// formation (16), position (17), playStyle (23) and managerLeagueModifier (24)
+/// their OWN segment strings, so those types are not folded into `development`,
+/// which is what the oracle's grouping would require. The unfiltered reading is
+/// therefore the better-supported one, but it is still a reading: what the
+/// SCREEN expects to list has not been observed, and one live capture of the
+/// development tab would settle it.
+///
 /// `training` and `contracts` are CONFIRMED on the wire, `development` was
 /// observed live, and the singular `contract` is accepted because the client has
 /// used both spellings. Segments are matched lower-cased.