CCSPlayerController_InventoryServices.m_rank appears to carry display item defidx values, not only MedalRank_t enum values

[unicbm]

Hi, I ran into an interesting schema/API mismatch around:

CCSPlayerController_InventoryServices.m_rank

CounterStrikeSharp currently exposes it as:

public Span<MedalRank_t> Rank => Schema.GetFixedArray<MedalRank_t>(..., "m_rank", 6);

and MedalRank_t only contains:

MEDAL_RANK_NONE = 0,
MEDAL_RANK_BRONZE = 1,
MEDAL_RANK_SILVER = 2,
MEDAL_RANK_GOLD = 3,
MEDAL_RANK_COUNT = 4,

However, in CS2 demos / live scoreboard behavior, this field appears to carry displayed medal/flair item definition indices. Examples observed from demo data include:

• 874 -> 5 Year Veteran Coin
• 4974 -> Champion at Perfect World Shanghai 2024
• 5313 -> Cologne 2026 Silver Coin
• 6132 -> Howl Pin

Writing those values back as raw uint values into the m_rank array and marking CCSPlayerController_InventoryServices::m_rank state-changed makes the scoreboard flair display correctly.

I also checked the current CS2 scripts/items/items_game.txt from game/csgo/pak01_dir.vpk. The valid display-flair values appear to be a sparse allowlist of item definition indices whose resolved schema slot is flair0, not a continuous numeric range. In my current local CS2 build this produced 621 valid flair0 item defidx values, ranging sparsely from 874 to 6134.

This makes the current Span<MedalRank_t> API somewhat misleading: the generated enum type suggests only 0..4 are meaningful, while real observed values are item definition indices.

Would you be open to one of these approaches?

1. Add a documented raw accessor/helper, e.g. Span<uint> / GetDisplayItemDefIndex / SetDisplayItemDefIndex, without changing the generated schema field.
2. Add a small extension/helper for CCSPlayerController_InventoryServices.m_rank that documents the item-defidx behavior.
3. Keep the generated API as-is, but document that callers may cast raw item definition indices through MedalRank_t for this field.

I am not sure CounterStrikeSharp should maintain the full items_game.txt-derived allowlist in core, because that data changes with CS2 updates. But exposing/documenting the raw item-defidx interpretation would make this much safer for plugin authors.