(bug) Answering an approval consumes it even when the resumed run never starts

[mmabrouk]

When I answer a parked approval and the resumed run fails to start, the approval is gone. It is
marked as answered before the run is known to have started, so there is nothing left to retry and
nothing that records that it failed.

I expect an approval to stay open until the run it unblocks has actually started, and to show me
that something went wrong when it has not.

Steps to reproduce

1. Run an agent until it parks on a tool that needs approval. A row appears in
   session_interactions with status pending.
2. Answer it: POST /sessions/interactions/{interaction_id}/respond.
3. Make the resumed run fail to start. Any 500 from the workflow service does it. In the case I
   hit, the agent's saved configuration was invalid ((bug) An agent with a bodyless skill runs in the playground and 500s everywhere else #5591).
4. The endpoint returns 200. The row is now responded. The run never started.
5. There is no way to answer that approval again, and no record anywhere that the resume failed.

What the code does

respond_interaction (api/oss/src/apis/fastapi/sessions/router.py:775) transitions the row to
responded first, and the transition is guarded so it can only happen once. Only then does it
enqueue the resume. The worker's failure is logged and dropped:

oss.src.core.workflows.types.WorkflowDetachedStartFailed:
  Workflow service returned HTTP 500 on detached start

Suggested shape

Either mark the row answered only once the resume has started, or transition it back to pending
when the start fails and record the error on the row so it is visible.

Notes

Found while testing the approvals work on #5562.

[linear-code]

AGE-4031