Return 404 on restore when instance not found

[sjmiller609]

Summary

Map instances.ErrNotFound to 404 in the RestoreInstance handler. Previously this surfaced as 500 internal_error because the handler's switch only checked for ErrInvalidState, with everything else falling through to the default 500 path.

This matches the existing pattern in ForkInstance and the other handlers in the same file. The RestoreInstance404JSONResponse type is already declared in openapi.yaml (line 2287) and generated into lib/oapi/oapi.go — no regen needed.

Observed in production: ~2 cases over the last 18h, all on `POST /instances/{id}/restore` with the error attribute `instance not found`. These should be 404, not 500.

Test plan

• CI green
• Manual: POST /instances/{nonexistent-id}/restore and confirm 404 with `{"code":"not_found","message":"instance not found"}`

---

Note

Low Risk
Low risk: only adjusts HTTP error mapping in the RestoreInstance handler, with no changes to restore behavior or state transitions.

Overview
POST /instances/{id}/restore now maps instances.ErrNotFound to a 404 not_found response instead of falling through to the generic 500 internal_error path. Other error mappings (e.g., ErrInvalidState → 409) are unchanged.

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

[firetiger-agent]

Monitoring Plan

This is a low-risk HTTP status code fix: POST /instances/{id}/restore now correctly returns 404 not_found when the instance doesn't exist, instead of falling through to 500 internal_error. The change is 5 lines, follows the exact same pattern as ForkInstance and other handlers in the same file, and touches no state machine or data logic.

What I'll watch for: Since Hypeman doesn't have trace/log tables in the Firetiger data lake, the primary health signals are invocation spawn success rates via kernel_invocation_spawn_total (baseline: 1,700–11,200 successful spawns/hr across prod-jfk-hypeman-0/1/2, zero failures in the last 3 days) and deployment duration via kernel_deployment_duration_seconds. The secondary signal is a reduction in 500s on the restore operation (the PR author notes ~2 spurious 500s in the last 18h that this fixes). The restore endpoint itself is extremely low-traffic with no observable volume in API metrics over the past 3 days.

Status updates will be posted automatically on this PR as monitoring progresses.

View agent