Prevent stale Created state after restore

[sjmiller609]

Summary

• publish the running hypervisor state after a successful restore resume
• prevent concurrent restore callers from observing a stale cached Created state and receiving a 409
• add a regression test covering two concurrent restores with a transitional state query

Tests

• go test -race ./lib/instances -run '^(TestConcurrentRestoreClearsTransitionalHypervisorStateCache|TestLifecycleNoopTransitionsReturnCurrentInstanceWithoutEvent)$' -count=1
• go vet ./lib/instances
• go test ./lib/instances -count=1 (integration tests requiring mkfs.erofs and completed local image builds could not run in this environment)

---

Note

Low Risk
Small, targeted ordering fix on the restore success path plus a unit test; no auth or data-model changes.

Overview
After a successful standby restore, restoreInstance now writes hypervisor.StateRunning into the hypervisor state cache immediately after metadata is saved and before building the API response. That clears a transitional Created value that can be left when a state query hits the VMM during RestoreVM (before resume finishes), which could otherwise make a overlapping restore see the wrong cached state and fail with a conflict.

A new regression test TestConcurrentRestoreClearsTransitionalHypervisorStateCache runs two concurrent RestoreInstance calls while the fake starter pins Created in the cache mid-restore; both completes succeed and only one restore runs.

^{Reviewed by Cursor Bugbot for commit cc9f608. Bugbot is set up for automated code reviews on this repo. Configure here.}

[yummybomb]

Looks good!

publishing Running before deriving the response correctly prevents the stale cache value from propagating into the lifecycle event and subsequent restore call. the focused concurrency test covers the regression well.