Fix games.status deadlock by eliminating double checkGameStatus call

[Copilot]

Fixes the issue where gabs.games_status({"gameId":"rimworld"}) would hang indefinitely due to a mutex deadlock.

Problem

The games.status tool was calling checkGameStatus() twice within the same execution path:

1. First call: getStatusDescription(game.ID, game) internally calls checkGameStatus() to get the status
2. Second call: Direct call to checkGameStatus(game.ID) for launcher-specific warning logic

Since checkGameStatus() acquires a mutex (s.mu.Lock()), this double acquisition could cause a deadlock under certain conditions, particularly with Steam/Epic launcher games like RimWorld.

Solution

• Modified the games.status tool to call checkGameStatus() only once and reuse the result
• Added new helper function getStatusDescriptionFromStatus() that accepts the status as a parameter instead of calling checkGameStatus() again
• Maintained backward compatibility by keeping the original getStatusDescription() function for other parts of the codebase

Code Changes

The fix eliminates the duplicate mutex acquisition while preserving all existing functionality:

// Before: Double checkGameStatus() call
statusDesc := s.getStatusDescription(game.ID, game)  // calls checkGameStatus()
// ...
status := s.checkGameStatus(game.ID)  // calls checkGameStatus() again!

// After: Single checkGameStatus() call
status := s.checkGameStatus(game.ID)  // call once
statusDesc := s.getStatusDescriptionFromStatus(status, game)  // reuse result

Testing

• All existing tests continue to pass
• Added specific test TestDoubleCheckGameStatusFix that validates the RimWorld scenario
• Verified no behavioral changes for end users

This is a minimal, surgical fix that resolves the deadlock without any breaking changes.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.