Add ai_runtime/asyc background execution as a processing mode for ai_automators

[Tracker]
Update Summary: Add an optional ai_runtime-backed async processing mode for ai_automators.
Check-in Date:
Metadata is used by the AI Tracker. Docs and additional fields dashboard/docs" title="AI Issue Tracker Documentation">here.
[/Tracker]

Problem/Motivation

ai_automators already supports several processing modes, including direct execution,
batch processing, queue/cron processing, and field widget processing. These are useful, but none
of them cleanly solve the case where AI field generation is too slow to run inside the original
request and still needs a better user experience than cron-based processing.

Direct processing blocks the request and risks timeouts. Batch processing is tied to interactive
batch UX. Queue/cron processing runs later, but does not provide an immediate background-runtime
style execution model. What is missing is a processing mode that starts immediately, runs in the
background, and can persist execution state and final results.

This is especially important for larger AI automations and future agentic workflows, where field
generation may involve multiple steps or longer provider response times.

Steps to reproduce (required for bugs, but not feature requests)

Not applicable. This is a feature request.

Proposed resolution

Add a new ai_automators worker type backed by ai_runtime, using
runner for detached/background execution.

The integration should:

• add a new automator processor option such as AI Runtime Async
• dispatch automator field generation through runner in detached mode
• attach the ai_runtime execution storage observer so execution state can be tracked
• update automator status correctly while work is running in the background
• save generated field values back onto the entity once execution completes
• avoid nested entity saves during entity save hooks, especially for revisionable entities like nodes

To keep responsibilities clear, the integration should live in a dedicated bridge module rather
than hard-coupling core ai_runtime directly to ai_automators.

Remaining tasks

• finalize the bridge module implementation and review the service boundaries
• ensure automator status updates behave correctly for multi-field async executions
• validate the integration end to end on revisionable entities such as nodes
• document the new worker type and when to choose it over direct, batch, or queue processing
• optionally expose execution IDs or execution-state visibility for better debugging and UX

Optional: Other details as applicable (e.g., User interface changes, API changes, Data model changes)

User interface changes

• adds a new worker option in the ai_automators field configuration UI

Architecture changes

• introduces an optional bridge between ai_automators and ai_runtime
• uses runner as the generic background execution engine
• uses ai_runtime for async execution storage and lifecycle tracking

Behavioral changes

• field generation can begin immediately while continuing in the background
• provides a clearer execution model for long-running AI automations than queue/cron alone

AI usage (if applicable)

[x] AI Assisted Issue

This issue was generated with AI assistance, but was reviewed and refined by the creator.

[ ] AI Assisted Code

This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision.

[ ] AI Generated Code

This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human.

[ ] Vibe Coded

This code was generated by an AI and has only been functionally tested.