prompt_async returns 204 before prompt persistence completes

[tracycam]

Description

The prompt_async handler forks the entire prompt operation, including user-message persistence, and immediately returns HTTP 204. A client can therefore observe a successful response before the prompt has been durably admitted. If the process or request scope ends in that window, the caller has no way to distinguish an accepted prompt from one that never reached storage.

Expected behavior

HTTP 204 should mean the user message has been persisted. Model execution can remain asynchronous.

Suggested change

Separate prompt admission from loop execution: await admission in the handler, then fork only the session loop when noReply is not set. A regression test can call promptAsync with noReply: true and immediately verify the message is present.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• prompt_async returns 204 after startup failure, leaving empty child sessions that appear frozen #33394: prompt_async returns 204 after startup failure, leaving empty child sessions — covers overlapping territory around the 204-before-durable-state contract; the root cause and scope differ but the proposed fix direction aligns closely
• promptAsync message persisted but session loop never scheduled — async wake prompts to idle session silently dropped #32010: promptAsync message persisted but session loop never scheduled — a related async-prompt lifecycle gap where persistence succeeds but execution is silently dropped