Fix Float Rank hyperlinks for Souvenirs/StatTraks

[rxl211]

I noticed that on Steam inventories, when you selected a StatTrak or Souvenir item and it had a displayed float Rank, clicking on the link would always take you to the database with a category=1 (Normal) filter selected, even though the selected item was StatTrak/souvenir.

Example:

The root cause seemed to be that the itemInfo.full_item_name field was never populated, and so downstream code which looks at full_item_name to derive the correct category filter when constructing the hyperlink would always just default to category=1.

This PR includes a change to selected_item_info.ts to populate full_item_name inside of processSelectChange().

I verified this fixes the bug locally by loading the unpackaged extension in Chrome. I did not test on Firefox.

---

Note

Low Risk
Localized inventory UI change with no auth or data-model impact; main behavioral change is correct hyperlink category plus ignoring outdated fetch responses.

Overview
Fixes float rank hyperlinks for StatTrak and Souvenir items in the Steam inventory panel by setting itemInfo.full_item_name from the selected asset’s market_hash_name after the inspect fetch. renderClickableRank / getFloatDbCategory use that field to pick the DB category filter (Normal vs StatTrak vs Souvenir); without it, links always used category 1.

Also guards against stale async updates when the user changes selection while a float request is in flight (compare assetid before applying results) and tightens null checks around the fetch path.

^{Reviewed by Cursor Bugbot for commit 28c14a9. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 6f5342d. Configure here.}

[GODrums]

Thanks for the contribution and finding this bug! Added a small comment to make our parsing a bit more reliable and resolve the issue in SCM as well

[GODrums]

Combining data points from different sources will make this process harder to reproduce in other places (e.g. the same issue occurs in our SCM enhancements).

I would prefer reusing our existing solution from fetch_inspect_info.ts

extension/src/lib/bridge/handlers/fetch_inspect_info.ts

Lines 134 to 135 in d46eac3

	const stattrak = decoded.killeaterscoretype !== undefined;
	const souvenir = decoded.quality === 12;

and just modify the string parsing in getFloatDbCategory to use the available info.

We could remove full_item_name from ItemInfo to make this a bit more clear.

[rxl211]

@GODrums thanks, I wasn't thinking about SCM! I did initially look at getFloatDbCategory but the problem I ran into is that ItemInfo doesn't contain anything to infer StatTrak from. I see now that you can infer souvenir by quality == 12 though, so that can be done easily.

Are you suggesting adding an is_stattrak property to ItemInfo in fetch_inspect_info.ts? I'm still unsure of what a common area would be to fill in the property. I tried doing so in fetch_inspect_info.ts but my new fields never showed up when I tried outputting the ItemInfo object to console.

I'm also not sure what kind of caching exists in the extension. But that's not the reason I don't think it was working for me because I tried going to SCM pages I had never been to before.