fix: replace time.Sleep with context-aware sleeps in doPressKey and doDragMouse

[rgarcia]

Summary

• doPressKey used time.Sleep for the key hold duration, blocking without respecting context cancellation while holding inputMu
• doDragMouse used time.Sleep for the optional pre-drag delay, same problem
• Both are especially problematic in the batch flow where the mutex is held for the entire batch

Changes

• Extract a sleepWithContext helper that uses select with time.NewTimer and ctx.Done()
• Refactor doSleep to use the shared helper
• Replace time.Sleep in doPressKey with sleepWithContext; on cancellation, best-effort release held keys using a background context
• Replace time.Sleep in doDragMouse with sleepWithContext; on cancellation, best-effort release mouse button and modifier keys
• No remaining time.Sleep calls in computer.go

Test plan

• go build ./... and go vet ./... pass
• go test ./cmd/api/api/... passes
• Verify key hold and drag delay are interruptible by cancelling a request mid-sleep

Made with Cursor

---

Note

Medium Risk
Touches low-level input simulation and cleanup behavior; cancellation paths now run xdotool releases via context.Background(), which could change how interrupted requests leave system input state.

Overview
Makes input-related delays context-aware to avoid blocking while inputMu is held (notably during BatchComputerAction).

Replaces time.Sleep in doPressKey key-hold and doDragMouse pre-drag delay with a shared sleepWithContext helper, and refactors doSleep to use it as well. On cancellation, both key-hold and drag delay now perform best-effort cleanup (releasing keys and/or mouse button) via context.Background() before returning an error.

^{Written by Cursor Bugbot for commit 90ff857. This will update automatically on new commits. Configure here.}

[az-rye]

🔥