Single-use request_info token replay behavior and regression coverage

[davidahmann]

Problem observed
When a workflow emits a request_info event, operators may retry a submit action if they are unsure the first response was accepted. The intended contract is single-use request IDs, but we did not have a direct regression test proving replay attempts are rejected.

Why it matters operationally
Without explicit replay coverage, a future refactor could accidentally re-accept stale request IDs. That would weaken deterministic human-approval semantics and make incident analysis harder because duplicate approvals could be interpreted as separate user intent.

Minimal repro

cd python
uv run pytest packages/core/tests/workflow/test_request_info_event_rehydrate.py -k replay --maxfail=1

Fix approach
I added a focused regression test around InProcRunnerContext.send_request_info_response:

• create one pending request_info event
• submit one valid response and assert the request ID is removed from pending state
• submit a second response with the same request ID and assert deterministic rejection (ValueError)

This keeps scope narrow: no runtime behavior change, only explicit contract coverage for replay safety.

Validation evidence

• uv run pytest packages/core/tests/workflow/test_request_info_event_rehydrate.py -k replay --maxfail=1 passed.
• The new test verifies pending map eviction after first response.
• The new test verifies replay rejection path with exact error message match.

Open follow-up question for maintainers
Would you prefer this single-use replay contract to be codified in a broader workflow/HITL contract document, or kept as test-enforced behavior at the runner-context layer?
Inspired by research context: CAISI publishes independent, reproducible AI agent governance research: https://caisi.dev