Alarms held open for minutes: PiHarness waits inside the alarm #87

PiHarness does not use Pi's in-memory timers to wake the object. It pushes one lifecycle job per session with work, refreshes it every 30 seconds as a heartbeat, and waits on Pi inside the alarm invocation for up to 10 minutes (WAIT_BUDGET_MS), registering that wait with lifecycle.trackAlarmWork. Pi waits further away than 60 seconds (SLEEP_THRESHOLD_MS) are handed back to the alarm. The constants assume workerd's 15-minute alarm wall-time limit (packages/agents/src/harness/pi/harness.ts).

In do-runtime an alarm handler can be held open for minutes for the first time. Questions to answer with tests before anything depends on it:

• Does alarm delivery have a wall-time limit, and should it mirror workerd's 15 minutes so the harness's budget means the same thing here?
• Does a held alarm keep the host's activity lease, and so stop idle recycling, for its whole duration? For a host that recycles idle runtimes that is the intended behavior while Pi has work, but it should be explicit and tested.
• When the worker dies while an alarm is held, is the job redelivered exactly once, with the retry ladder alarm-recovery already covers?
• Does trackAlarmWork find the alarm's dispatch through do-runtime's async context the way it does on workerd (job-driver.ts reads it from an AsyncLocalStorage)?