After-start prompt delivery can be lost for interactive TUI agents

[nikhilachale]

Summary

Workers using after-start prompt delivery can spawn into an idle TUI without receiving the initial task prompt.

I observed this with cline and kimi: AO created the sessions and stored the prompt, but the agent panes remained at their
empty input screens and no prompt activity signal was recorded.

Evidence

Recent sessions had the prompt persisted in SQLite:

• renz-ui-48 / cline / prompt: add good morning message in hero section
• renz-ui-49 / kimi / prompt: add good morning message in hero section

But both panes were idle at the TUI input prompt, and first_signal_at was empty for both sessions.

Kiro behaved differently: renz-ui-50 launched with the prompt in argv:

kiro-cli chat --agent ao -- "add good morning message in hero section"

and had first_signal_at populated, so this appears specific to PromptDeliveryAfterStart.

## Likely Cause

For agents returning PromptDeliveryAfterStart, the session manager creates the runtime and immediately calls
m.messenger.Send(...):

- backend/internal/session_manager/manager.go
- after-start handling around prompt stripping and post-spawn send

Cline and Kimi both rely on this path:

- backend/internal/adapters/agent/cline/cline.go
- backend/internal/adapters/agent/kimi/kimi.go

The prompt is probably sent before the interactive TUI is ready to accept input, so the keystrokes are lost or ignored.

## Expected Behavior

When a worker is spawned with a prompt, the agent should reliably receive and submit that prompt, or AO should fail the spawn
instead of leaving an idle worker.

## Actual Behavior

The worker appears live, but it is just sitting at the agent TUI with no task running.

## Suggested Fix

Add reliable readiness handling for PromptDeliveryAfterStart, such as:

- wait until the pane output matches an agent-specific ready/input state before sending
- retry delivery if no first signal/activity is observed shortly after send
- add adapter-specific delivery implementations where generic tmux keystrokes are unreliable
- surface a spawn warning/error if prompt delivery cannot be confirmed