Add SpriteWakeCoordinator for reliable sprite wake-up

[zmanian]

Summary

• Extracts sprite wake-up logic into a testable SpriteWakeCoordinator that polls status, retries wake pings on a configurable interval, and distinguishes genuine network failures from transient server errors (e.g. 503 during warm-up)
• Adds wakeSpriteIfNeeded convenience method on SpritesAPIClient
• Integrates into ChatViewModel (pre-wake before sending, skip question tool install on timeout) and DashboardViewModel (replaces manual polling loop)
• 4 unit tests covering: already-running, wake transition, server error timeout, and network failure escalation

Test plan

• Verify wake from dashboard works for cold/warm/running sprites
• Verify chat send pre-wakes sprite and proceeds even on slow warm-up
• Verify question tool install is skipped gracefully when sprite is still warming
• Run unit tests: all 4 SpriteWakeCoordinator tests pass

Generated with Claude Code

[mcintyre94]

Can you explain the motivation for this one a bit? Sprites should wake on their own when we call them, and I think doing an extra wait for them to wake before calling them is just going to add latency. Especially because there isn't an actual wake command, just a no-op exec, which AFAIK just wakes it in the same way as any other call.

[zmanian]

Good question. Two motivations:

1. Reliability on cold starts. In real-world usage, sending a chat message to a cold sprite would hang — the WebSocket exec connects but the sprite isn't actually ready to run commands yet, leading to timeouts or silent failures. The coordinator polls status until it sees running before we start the exec, so the Claude command hits a sprite that's ready.

2. Centralizing wake logic. Wake-related code was scattered across ChatViewModel, DashboardViewModel, and the loop flow — each with its own polling/retry approach. The coordinator extracts that into a single testable component that all callsites share.

That said, if the Sprites API now reliably blocks/queues exec calls until the sprite is warm, the pre-wake step is unnecessary overhead and I'm happy to close this. Do exec WebSocket connections wait for the sprite to finish waking now, or do they still connect immediately?

[mcintyre94]

In real-world usage, sending a chat message to a cold sprite would hang — the WebSocket exec connects but the sprite isn't actually ready to run commands yet, leading to timeouts or silent failures.

This is what I can't reproduce - when I send a message to a cold sprite it just shows the "Connecting..." status for a few seconds and then starts streaming. The Connecting status is basically a wake up, it's just done with a sprite exec command

Do exec WebSocket connections wait for the sprite to finish waking now, or do they still connect immediately?

The exec command should definitely be waiting for the sprite to wake and then responding!

I think my more general view here is that the sprite platform is designed around being fast to start/stop, and automatically starting when it receives requests. I'm trying to design to/take advantage of the way the platform works, and I think custom wake logic should be unnecessary in general.