fix: avoid out-of-bounds array access in modelinfomgr

[CanerKaraca23]

🎯 What: Removed a hacky data.nFrameCount <= 10 check used to workaround a crash and replaced it with strict bounds checking before accessing m_SirenStatus and m_StrobeStatus arrays based on GetSirenIndex / GetStrobeIndex.

💡 Why: The frame count check delayed the bug but didn't actually fix the root cause, which was out-of-bounds array reads. Checking the index ensures memory safety regardless of the frame counter, which is cleaner and less susceptible to race conditions.

✅ Verification: Verified by a code reviewer confirming the logical correctness of checking array limits idx >= 0 && idx < MAX_LIGHTS before proceeding with the read. Avoided polluting the repo with compile_commands.json or plugin-sdk downloads.

✨ Result: Improved crash resilience and robustness for vehicle material rendering without arbitrary frame delay workarounds.

[Copilot]

Pull request overview

This PR hardens ModelInfoMgr::SetEditableMaterialsCB against out-of-bounds reads when resolving siren/strobe material states by validating indices returned from GetSirenIndex / GetStrobeIndex, removing the prior frame-count-based workaround.

Changes:

• Removed the early-return “frame count <= 10” workaround for siren materials.
• Added explicit bounds checks before reading m_SirenStatus[] and m_StrobeStatus[] using the computed indices.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AmeerDotEXE]

added back the siren check, it will be removed by the next pr. thanks for helping :D
edit: don't worry about build fail, i'll update plugin-sdk after all pr