VM lifecycle: suspend, resume, idle timer, suspend cap, eight-hour cap

[lex00]

Stacked on #34 — base is feature/6-recording, so review that one first.

SuspendMicrovm walks RUNNING to SUSPENDED through SUSPENDING on the clock. ResumeMicrovm goes SUSPENDED straight back to RUNNING with no state between, per the recorded asymmetry: the same five-second poll that caught PENDING on the initial launch saw nothing at all on the way back, and the enum has no RESUMING to occupy anyway.

The generation counter

clock.Clock has no cancel, by design. Each VM carries a counter bumped on every state change; a timer captures it when armed and does nothing if the VM has moved on. That is what makes a resume during SUSPENDING safe — the in-flight transition finds a changed generation and declines to land — and what stops the first suspension's cap from reclaiming a VM that has since suspended a second time. Traffic resets reuse the shape: the idle timer fires, finds activity newer than it expected, and re-arms for the remainder.

The three timers: maxIdleDurationSeconds without endpoint traffic moves RUNNING to SUSPENDING, suspendedDurationSeconds in SUSPENDED reclaims the VM, and eight hours ends the session whatever state it is in.

The state marker

A monotonic counter Touch bumps and nothing resets, so #12's endpoint stub can serve it back across a suspend and resume to prove the VM was not rebuilt. Deliberately absent from the GetMicrovm body — it is m80's own instrumentation, and putting it on a modeled response would be an invented member on the wire. TestMarkerIsNotOnTheWire pins that.

Scope note: VM state is now serialized

Transitions run on clock callbacks, which under clock.Real are separate goroutines, while handlers read the same fields to build a response. Every test used clock.Test, whose callbacks run on the test goroutine, so -race could never see the collision. Probing the unmodified tree under -race shows it plainly:

WARNING: DATA RACE
Write at 0x00c0001781f0 by goroutine 16:
  vms.(*Service).Run.func1()  internal/vms/vms.go:115
Previous read at 0x00c0001781f0 by goroutine 10:
  vms.detail()                internal/vms/handlers.go:164

Handlers now render a snapshot taken under the service mutex, and TestTransitionsAndHandlersDoNotRace runs the real clock so the detector has something to look at. #11 adds three more timers per VM, so this could not wait.

Unrecorded behavior, and what I guessed

Suspending an already suspended VM, or one on its way to TERMINATED, is a no-op answered 200; PENDING is allowed through. None of that was recorded. Idempotence is the safer guess than an invented error for a reconciler that may re-issue the call. The one recorded case is pinned: any mutation of a TERMINATED VM is a plain 400 ValidationException, neither modeled conflict type, which is what case 82 asserts.

Cap-driven termination reports stateReason: "Success.", same as an explicit one. The service's wording for those paths was never recorded and a different string would be invention.

Optional steps

ResumeMicrovm was never sent by the suite at all: auth-token-while-suspended is #12's operation and sits between suspend and resume in case 40, so its 501 halted the case first. #11's acceptance asks that the resume transition match the recorded fixture, and there was no way to show it.

"optional": true on a step exempts it from halting its scenario when the target answers 501, and nothing else — a step that genuinely fails still halts however it is marked, and a step carrying capture should never be marked. Both halves are pinned by tests.

vm-suspend-resume now runs end to end, and resume and get-until-running-again pass against their recorded fixtures.

Result

52 pass, 0 fail against a fresh m80, up from 43 on the parent. 23/29 operations exercised, up from 22. go build, go vet, gofmt and go test -race clean.

Closes #11