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
Small change to URL query parameters for rank links; logic mirrors existing inspect-based StatTrak/Souvenir detection with no auth or data migration impact.

Overview
Fixes Rank links on csfloat.com/db always using category=1 (Normal) for StatTrak and Souvenir items when float rank is shown from inspect data.

ItemInfo now includes is_stattrak and is_souvenir, set in fetch_inspect_info from the decoded inspect payload (same rules already used for rank eligibility: kill-eater score type and souvenir quality 12). getFloatDbLink in skin.ts picks category 2 / 3 / 1 from those flags instead of substring checks on full_item_name, which was often unset so links defaulted to Normal.

^{Reviewed by Cursor Bugbot for commit ec3168e. 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]

Please also ensure to run the linter so our tests pass (npm run lint)!

[rxl211]

I think the tests should pass now. Looked like Prettier was failing on a stray blank-line whitespace. That passes now on my machine.

npm run checkformat in my Windows workspace is reporting many unchanged files because of line end differences but I don't think that'll show up when Github runs the tests.