🤖 fix: Daytona startAndWait can start a sandbox after its deadline and then report a timeout #7463

Follow-up from the Codex review of #7100 (thread: #7100 (comment), src/node/services/daytona/daytonaSandboxes.ts:184).

Problem

DaytonaSandboxes.startAndWait sends the start request before it checks the deadline. When a sandbox stays in a transitional state (for example stopping) for most of the wait and the last poll after the deadline reports stopped, Xum starts the sandbox and then throws a timeout. The caller sees a failure, but the sandbox runs and bills until Daytona's auto-stop stops it (30 minutes after the last activity).

Proposed fix

Check the remaining time before the start step, and throw the timeout without a start request when the deadline has passed. Add a test with a sandbox that reports stopping until the deadline and stopped after it, and assert that no POST /sandbox/<id>/start is sent.

Why it is deferred

#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up. Daytona's auto-stop bounds the cost of a sandbox started this way.