Larger RL models cause locationd errors on long drives

[tfpgh]

This issue can be seen in this segment from @Karnbir.

Not 100% confident but seems like:

• camerad's msgq endpoint for each camera stream has 15 reader slots. These aren't reclaimed when a VisionIpcClient is destroyed
• When the car passes through 5m/s, the UI switches the displayed camera by creating a new VisionIpcClient, which consumes another reader slot for the target stream
• Before this error, there had been 13 fcam to ecam transitions during the drive. Those + modeld reader + encoderd reader filled all 15 ecam slots
• When the car slowed below 5m/s again, the UI registered a new client which reset all all existing reader slots, including modeld's ecam reader
• With the RL model, modeld finished processing frame 28087 ~4ms after the reset. The smaller, 7ms faster model, probably would have let modeld recieve the ecam frame before the reset
• When modeld tried to read the next ecam frame it had to re-register it's reader. This skipped over frame 28088 so modeld ran on ecam frame 28089 and fcam frame 28088
• On the next iteration, modeld ran on frame 28090 from both streams. It detected the dropped fcam frame 28089 and marked cameraOdometry with valid=false
• locationd tolerates one bad camera-odometry input as long as it reject it itself. If it comes in marked as valid=false, locationd immediately makes inputsOK=false

Seems like a lot went wrong here. This might cause issues on big models as well but not sure how specific the timing issue is.

[Karnbir]

Here are a couple of more segments where I got LocationD errors:
https://connect.comma.ai/7bc0de9da607c543/00000112--c8ce57aeda/2385/2401
https://connect.comma.ai/7bc0de9da607c543/0000010c--f81d39e070/1442/1455

[GavinnnK]

I reproduced this at the msgq layer on current commaai/msgq master (deecc5d). A persistent SubSocket is evicted after creating and destroying NUM_READERS transient subscribers. The regression test fails on master (14/15 tests pass) because the persistent subscriber drops the next message after re-registering.

I have a local patch that:

• releases a reader slot on queue close only when the slot UID still belongs to that subscriber;
• reuses vacant slots before extending the reader-slot high-water mark;
• skips vacant/reserved slots in publisher notification, wait, and all_readers_updated() paths;
• keeps the shared-memory layout and NUM_READERS unchanged; and
• adds a public-SubSocket regression test matching the create/destroy behavior from VisionIpcClient.

With the patch, the C++ suite passes 15/15, the 29 Python unit tests pass, and the static checks and ASAN run pass. The existing full-capacity eviction behavior remains for a genuinely full or stale reader set.

If this approach matches the intended msgq semantics, I can open the fix in commaai/msgq first and then follow up with the openpilot submodule bump.