fix: Response completion uses an unbounded context for durable-ID lookup and can leave runs stuck in_progress forever

[sam-saffron-jarvis]

What changed

• replaced the unbounded context.Background() durable response-id lookup on the response completion path with a short best-effort lookup that uses context.WithTimeout(context.WithoutCancel(runCtx), 5*time.Second)
• fall back to the ephemeral resp_* id if the durable-id lookup errors or times out, so completion still proceeds and terminal events are emitted
• added focused tests covering both the successful durable-id path and the timeout fallback path, including preservation of parent context values without inheriting cancellation

Why this is high-value

This is on the core /v1/responses success path. Before this change, a completed model run could block forever waiting for GetLatestVisibleMessageID on the single pooled SQLite connection, because the lookup used an unbounded background context. When that happened, the run never reached run.complete(...), clients never received response.completed / [DONE], the session stayed busy, replay subscribers hung, and shutdown waited on the stuck run.

Bounding the lookup and treating it as best-effort preserves the intended durable-id behavior when the store is healthy, while guaranteeing the run can still finish and clear its active-run bookkeeping if the store is slow or wedged.

Validation

• gofmt -w cmd/serve_response_runs.go cmd/serve_response_runs_test.go
• go build ./...
• go test ./...
• git diff --stat
• git diff --check

[SamSaffron]

Implemented in local copy: durable response-id lookup on completion now uses a bounded best-effort context and falls back to the ephemeral response id on lookup failure/timeout. Verified with go build ./... and targeted tests.