Human-in-the-loop response is accepted after the task has stopped waiting #75531

Under which category would you file this issue?

Airflow Core (API, UI)

Apache Airflow version

main (57a4751c967)

What happened and how to reproduce it?

PATCH .../taskInstances/{task_id}/{map_index}/hitlDetails records the response whenever the
request has none yet. It resumes the task only if the task is still awaiting_input or deferred.

When response_timeout passes with no defaults, the scheduler fails the task without writing a
response. A response submitted afterwards is therefore stored and answered with 200, and the UI shows
"response successful", but nothing resumes. The task stays failed, and the history shows a decision
that never took effect.

Reproduce:

1. ApprovalOperator(subject="...", response_timeout=timedelta(seconds=20)), with no defaults
   and retries=0.
2. Open its Required Actions page, then wait for the task to fail on timeout without reloading.
3. Click Approve in the page that is still open. The UI reports success and the history records the
   approval. The task and its downstream tasks remain failed or upstream_failed.

A freshly opened page disables the buttons. Only a page loaded before the timeout lets this through,
and the API accepts it from any client.

What you think should happen instead?

A response to a request whose task is no longer waiting for it is refused, for example with 409, with
a message that the request expired or the task stopped waiting. It should not be recorded as a
decision.

Anything else?

• The task failing and not reviving is correct; the problem is the success feedback and the stored
  answer.
• The new request_created_at check (Refuse a HITL response for a request the task has since replaced #74688) refuses answers to a replaced request, but not to
  one whose task has stopped waiting.
• This applies to every HITL operator, not one SDK.

Drafted-by: Claude Code (Opus 5.5) (no human review before posting)