fix: align picker position counter with the items-list filter

[pangin]

Potential issue

The modal accessory picker has three functions that each construct or address into the same logical "items list" for a slot — [none, owned-and-loaded items in ItemRegistry order, unowned items]:

Function	Role	"Loaded" filter applied?
cycleSlotItem	builds list on arrow nav	yes (idx >= 0 in hatNames / faceNames / etc.)
getSlotItemInfo	reads list each draw	yes (same lookup)
syncItemIndices	restores cursor on open	no — counts every owned item from ItemRegistry

When the two sets disagree — that is, the profile owns an item whose id is in ItemRegistry but not in the renderer's loaded *Names slice — syncItemIndices advances idx for it while cycleSlotItem and getSlotItemInfo do not. The picker cursor lands one position past where the item actually appears in the visible list.

Concrete consequences for SlotHat with one mid-registry hat missing from hatNames:

• Every hat that appears AFTER the missing one in ItemRegistry is rendered as the NEXT hat in the items list (off-by-one).
• The LAST hat in ItemRegistry yields pickerItemIndex[slot] == len(items), which trips getSlotItemInfo's defensive pos >= len(items) guard and silently falls back to position 0 ("none").

The visible symptom is: after equipping a high-registry-position accessory and closing/reopening the picker, the slot displays as empty.

When can the drift happen?

Any time ItemRegistry and the renderer's *Names slice diverge. Examples:

• A packaged asset bundle that omits a .png (e.g. an older release whose asset list lagged behind a new ItemRegistry entry).
• A runtime texture-load failure for one accessory (permission error on a specific file, partial download, …).
• A future ItemRegistry entry added in code before its asset is committed.

In each case, the current code drops the equipped accessory's visual state on the next picker open, which is hard to attribute and easy to misread as a save/load bug.

Fix

Add the same "loaded" filter to syncItemIndices so all three functions agree on counting. The filter is a single nameSet lookup and short-circuits identically to the existing two call sites.

nameSet := make(map[string]struct{}, len(names))
for _, n := range names { nameSet[n] = struct{}{} }

for _, item := range ItemRegistry {
    if item.Slot != slotType { continue }
    if r.profile != nil && !r.profile.IsOwned(item.ID) { continue }
    if _, loaded := nameSet[item.ID]; !loaded { continue }  // ← added
    if item.ID == currentID { pos = idx; break }
    idx++
}

No change for the happy path (all owned items also loaded) — nameSet lookup is true for every owned item, so position counting is identical to before.

Tests

renderer_picker_modal_test.go (new file) constructs a minimal Renderer (no raylib resources touched) and verifies:

• Happy path — all hats loaded; mid-list and last hat both resolve to the position that the items-list builder would produce.
• Drift case — one mid-registry hat removed from hatNames while the profile still owns it. Every hat after the missing one (and the last hat in particular) resolves to its correct visible position, no longer overshooting.
• Unowned items not counted — profile owns only the last hat in ItemRegistry; cursor must land at position 1 (just after "none"), not advance for unowned earlier items.
• No equipment → position 0 — currentHat == -1 clears any stale pickerItemIndex value.

Tests compile cleanly; full go test requires raylib's DLL on PATH (package init loads it), which the project's CI provides.