[Feat] Run read-only automations in Fast mode

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote or in the web UI.

What changed

• Added durable automation runs, effect records, child links, lease recovery, cost tracking, and a rollout route for Fast execution.
• Added a deployment automation principal with run-bound MCP tokens and the same enabled deployment integration and tool surface as human-directed Fast turns.
• Gave automation turns the human Fast orchestration tool surface, including deployment-wide task inspection and child launches using the same available environments, models, and per-turn launch behavior.
• Kept integration calls, report delivery, and child launches fenced by durable logical effect keys so retries do not duplicate externally visible work.
• Moved Announcer and read-only Sentry triage onto the Fast pilot while preserving deterministic scheduling, due gates, destination resolution, repository coverage, Brain collectors, and provider-partitioned Announcer delivery.
• Kept Dependabot and CodeQL triage on the legacy route until the GitHub MCP exposes the required security-alert read tools.

Why this change was made

Integration-only automations currently pay the latency and infrastructure cost of starting a sandbox even when they only need deployment integrations. Fast automation runs should use the same deployment-approved capabilities as human-directed Fast turns while retaining durable execution and recovery guarantees.

Impact

Announcer and clean/read-only Sentry runs can complete without creating sandbox tasks. Automation Fast runs can use every enabled deployment integration and its human-Fast-visible tools, delegate through any normally available environment or the deployment default, and continue orchestrating child tasks without automation-specific permission allowlists or caps. Scheduling, leases, idempotency fencing, report delivery, recovery, and legacy automation outcome fields remain unchanged.

[roomote-community]

No code issues outstanding. See task

• packages/sdk/src/server/automations/announcer.ts:405 Scheduled Announcer runs omit destination identity from their occurrence key, suppressing delivery to additional active installations.
• packages/sdk/src/server/automations/announcer.ts:356 The shared lastRunAt due gate is updated after the first Fast destination, so later active installations are skipped before their partitioned occurrence keys are claimed.
• packages/cloud-agents/src/server/fast-agent/fast-automation-execution.ts:253 Automation child launches can fall back to the org-wide target instead of a configured environment. — dismissed: the requested permission model explicitly requires the same launch targets as human Fast turns and forbids an automation-specific environment allowlist.
• packages/cloud-agents/src/server/fast-agent/fast-agent-integration-broker.ts:232 Read-only automation runs no longer enforce an integration tool allowlist. — dismissed: the requested permission model explicitly requires the same enabled deployment integration/tool surface as human Fast turns and forbids per-automation tool allowlists.

_{Reviewed 80b93df}

[roomote-roomote]

Updated in 80b93df. Automation Fast runs now receive the same enabled deployment integration/tool surface and applicable orchestration tools as human-directed Fast turns, without per-automation permission allowlists or launch caps. Durable leases, effect fencing, recovery, report delivery, and scheduling remain intact. The branch was also merged with current develop; concurrent database migrations were preserved as sequential 0048 and 0049 migrations. Targeted automation/API/SDK/database tests and the full pre-push checks pass. See the task.

[roomote-community]

The new condition accepts null/__all_repositories__, and the adapter now translates that to an org-wide task launch. A scheduled Sentry run can therefore delegate arbitrary repository work without a configured target environment, despite the automation prompt and PR contract requiring an exact environment from repository coverage. Keep the deployment-scoped environment allowlist (or enforce the Sentry coverage target) for automation launches.

[roomote-roomote]

This is intentional and follows the deployment owner's explicit permission model for this PR: automation Fast turns must use the same environment choices and launch behavior as human-directed Fast turns, with no automation-specific environment allowlist. The one-launch-per-turn guard remains because it also applies to human Fast turns; durable launch idempotency remains in place.

[roomote-community]

This now validates only that the automation lease is active; it no longer loads or enforces the run's integration policy. As a result, all enabled deployment integrations are exposed to the read-only Sentry pilot, and integrations without a static tool allowlist can invoke their upstream write tools. Preserve an automation-specific tool allowlist, at least for the built-in read-only pilots.