fix(turns): carry the asked question into a rebuilt prompt

[haiderysfzi]

What changes

A prompt rebuilt for an agent with no native session now carries the
<facility-needs-attention> question that the human's reply is answering. The
question is rendered against the agent message that asked it, so the transcript
reads question then answer.

Why

Closes #344.

agentOutcome (dispatcher.ts:669-674) strips the question out of the output, and
completeTurn persists only the stripped body, so the question survives on the
attention item alone. buildPrompt builds its transcript purely from
story_messages. An engine resuming its own native session still holds the
question in context, which is why this is invisible on the common path. When the
reply goes to a different agent, the session lookup keys on
agentName + engine + model (dispatcher.ts:169-177), no session matches, and the
rebuilt prompt is all the agent gets: No, continue. with nothing it answers.

Two details are worth naming, because both are easy to get wrong.

Attention status is deliberately not filtered. Dispatch resolves the item as
replied at dispatcher.ts:100-107, before the prompt is built, so an
status === "open" filter would drop precisely the question being answered.

The question is placed on the agent message only. Both the user and the agent
message of a turn carry that turn's turnId (stories/service.ts:367), so keying
on turnId alone renders the question twice and once in the wrong place.

Only agent_waiting items are rendered; queued_turn_dispatch_error is an
operational failure rather than a question. Details are already redacted at write
time via redactString, so nothing new is exposed.

Verification

New integration test: a builder asks a question, the reply is routed to a
different agent, and the rebuilt prompt is asserted to contain the question, the
answer, the question exactly once, and in that order. It also asserts
nativeSessionId is undefined, so the test fails rather than silently passing if
the fresh-session premise ever stops holding.

Mutating dispatcher.ts on this branch, running turn-dispatcher.integration.test.ts:

mutation	new test	other 9 tests
drop the question rendering	fails	pass
filter attention to status === "open"	fails	pass
drop the role === "agent" guard (question renders twice)	fails	pass

Each mutation is caught only by the new test, so the assertion is load-bearing
rather than incidental. The middle row is the one the existing suite could never
have caught.

Full runs, services/api, split across the databases the suite expects:

• facility_test (all but the e2e journey): 43 files passed, 407 tests.
• facility_ws (facility-012.e2e.integration.test.ts): 2/2, exit 0.
• pnpm verify: exit 0. Guards 2/2, audit clean against the ignore list.

One pre-existing failure, test/oauth.test.ts (500 on dev login), is unrelated
and reproduces without this change. Same command, same freshly created database,
this branch stashed: main gives 406 passed with that same single failure, this
branch 407 with the same single failure. The delta is exactly the one added test.

Note for @Yeeway69

The reproducer in the issue asserts a sha256 of dispatcher.ts to pin the
revision, and the file has changed since c14bc6d (in b2a9b47), so the script
now aborts on that assertion rather than running. The defect itself was untouched
by that commit and reproduces on current main. Thanks for isolating the seam so
precisely, it made this a small change.

[adrian-lorenzo]

Thanks for fixing this.

The change restores the missing context in #344, and the regression test covers the handoff well. I verified the fix and found no blocking issues.

[haiderysfzi]

Thanks for fixing this.

The change restores the missing context in #344, and the regression test covers the handoff well. I verified the fix and found no blocking issues.

Thanks for the review! Let me know if you'd like any changes before merge, or if there's a next issue to grab.