Refactor and upgrade Automation (Trigger) feature setup

Problem and outcome

Refactor and upgrade Automation (Trigger) setup and execution contracts so scheduled and conditional work uses a verified environment, a recorded configuration revision, explicit Session behavior, and predictable delivery policies.

Companion UX/UI issue: #1928. That issue owns the workflow and presentation; this issue owns the supporting validation, persistence, API, and execution behavior.

Execution readiness

• Verify model access, required files and context, installed skills, executable MCP tools, connector authorization, permissions, and supported Workspace Bundle capabilities on the selected execution destination.
• Return actionable missing or unsupported requirements; do not equate a saved Bundle with an executable setup.
• Revalidate relevant requirements before execution and expose stale or revoked access as setup required.
• Expose runtime availability and execution prerequisites to the UX.

Versioned execution setup

• Record the Workspace Bundle revision, runtime version, model configuration, and input for each execution.
• Define whether future executions retain a selected revision or explicitly adopt updated Space or Bundle configuration.
• Keep retries tied to the recorded setup.
• Store secret references and binding metadata rather than secret values in history.

Session continuity

• Support starting a new Session per execution or continuing a selected Session.
• Keep reusable agent configuration in the Workspace Bundle and working history in the Session.
• Persist the resulting Session association for each execution.

Repeat, overlap, and recovery policies

• Distinguish running when a condition becomes true from running repeatedly while it remains true.
• Persist event IDs or polling cursors and deduplicate deliveries.
• Define queue, skip, or supported concurrency behavior when work overlaps.
• Make retries respect completed external actions to avoid duplicate writes or messages.
• Define whether missed executions count toward automatic deactivation and whether reconnect can catch up eligible work.
• Expose missed, skipped, deduplicated, and deactivated outcomes with reasons.
• Ensure catch-up, retries, and overlap policies work together.

Scheduling correctness and testing

• Validate effective first-run timing and reject expired one-time selections at admission.
• Preserve one-time intent through is_single_execution, verify backend scheduling behavior, and ensure a one-time schedule cannot unintentionally recur.
• Provide a Run now execution path using the same relevant readiness and execution contracts as scheduled work.
• Return the effective timezone and next execution time for the UX.

Execution observability

• Emit authoritative delivery and execution lifecycle outcomes from the responsible backend, including misses and automatic deactivation when the desktop is offline.
• Correlate events with opaque execution identifiers.
• Exclude prompts, file contents, credentials, and personal data from analytics payloads.

Acceptance criteria

• Readiness checks return actionable requirements and prevent unsupported execution.
• Executions and retries retain their recorded configuration revision.
• Fresh and continuing Session modes route work correctly.
• Deduplication, conditional repetition, overlap, missed-execution recovery, and retry semantics are defined and tested.
• One-time schedules preserve intent and do not recur unintentionally.
• Run now and scheduled execution use consistent setup validation.
• Backend lifecycle events support the states and recovery actions in #1928.
• Existing Trigger API and persisted identifiers are preserved except for deliberate, compatible contract extensions.

Moving execution to an always-on worker or making it independent of the desktop remains a separate infrastructure scope.