fix(moe): prevent crash when persistent buffer slots are exhausted

[solderzzc]

Problem

SwitchGLU.callAsFunction crashes with _assertionFailure (force-unwrap of nil) in the warm-path hit/miss slot resolution when all persistent buffer slots are consumed by speculative hits:

Thread 5 Crashed:: com.apple.root.user-initiated-qos.cooperative
0  libswiftCore.dylib  _assertionFailure
1  SwiftBuddy          SwitchGLU.callAsFunction(_:_:) + 12024

Root cause: Line 726 uses a force-unwrap:

let freeSlot = (0..<maxBuffers).first { !usedSlots.contains($0) }!

When ranges.count == maxBuffers (typically 8 for top_k=8) and every expert in ranges gets a unique slot from the speculative-prefetch hit map, there are zero free slots remaining for any miss — .first returns nil and the ! crashes.

Fix

Replace the force-unwrap with a guard let that sets a slotExhausted flag and breaks out of the loop. When detected, the partial buffers are cleared and we fall through to the existing full-pread fallback path (same code as the no-predictions branch). Same correctness, no crash.

Fixes SharpAI/SwiftLM#87

[Copilot]

Pull request overview

This PR fixes a crash in the SwitchGLU.callAsFunction warm-path SSD streaming logic when resolving expert-to-persistent-buffer slots, by removing a force-unwrap that could trigger an _assertionFailure and cleanly falling back to the existing full-pread path.

Changes:

• Replace force-unwrapped free-slot selection with a guard let that detects slot exhaustion and exits the warm-path loop safely.
• Skip miss-only preads when slot exhaustion is detected, and instead trigger the existing full-pread fallback.
• Consolidate “no predictions” and “slot exhausted” handling into a single fallback condition based on usedGate.count != ranges.count.

---

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