Run scanner-selected agent turns as tracked child runs

[neubig]

Problem or Use Case

The Automation service can dispatch an automation bundle into a conversation runtime, and event triggers can append follow-up messages to an existing subject conversation. It cannot represent agent work selected by a deterministic scanner as a separate tracked run. Reusing the scanner's own run would couple orchestration code to the agent conversation and prevent one scanner from starting several independent jobs.

Desired Behavior

Add an internal service-owned agent-turn run. It stores a conversation turn and stable subject identity, provisions the existing conversation backend, runs the turn through software-agent-sdk, records normal run status and telemetry, and releases a completed Docker runtime while retaining conversation history.

Local admission should continue preventing overlapping executions of one scanner, while allowing that scanner's independent agent-turn runs to fan out up to the existing global conversation concurrency limit.

Subject identity must include its source so equal opaque keys from GitHub, Slack, or another integration cannot collide. Existing event-triggered conversation continuation should use the same source-aware locking and lookup.

Acceptance Criteria

• A queued agent-turn run stores its prompt, wake behavior, source, subject key, profile snapshot, and deterministic conversation ID.
• The dispatcher executes the stored turn through the existing conversation backend and software-agent-sdk instead of executing the scanner bundle again.
• Successful turns reach a terminal run state and release Docker runtime resources while conversation history remains.
• Failed turns mark the subject unavailable for routing and follow existing failure reporting.
• Local dispatch permits independent agent-turn runs to fan out up to AUTOMATION_CONVERSATION_MAX_CONCURRENT_RUNS while preventing overlapping scanner runs.
• Subject locks and lookups namespace external keys by source.
• Existing webhook-created runs snapshot profile and execution mode as scheduled runs already do.
• PostgreSQL and SQLite migrations and focused tests cover the behavior.

Additional Context

This is the internal execution prerequisite for #463. #463 adds the scoped API and idempotency record through which a running scanner creates these runs.

[github-actions]

✅ ready-for-dev label applied

This issue meets the readiness criteria and is ready for contribution.
A contributor can now open a PR that links this issue (Fixes #<number>).

This is an automated check — no AI was used to generate this comment.