Trigger a single automation run on demand, via CLI, API and UI

[Flix6x]

Problem

Automations only ever run on their own cron cadence (flexmeasures jobs run-automations, see #2288 and #2392). There is no way to run one now, on demand.

That is awkward in several everyday situations:

• After creating or editing an automation, you want to see it work rather than wait for the next occurrence, which may be a day away.
• After a failure (a bad regressor, a data source that was down, a scheduler misconfiguration), you want to re-run the same automation once the cause is fixed, instead of waiting for the next occurrence to find out whether the fix worked.
• After late or corrected input data arrives, you want to refresh the forecast (later: schedule or report) it feeds.
• While developing or demoing, you want a single button that produces data now.

Today the workarounds are to temporarily rewrite the cron string, or to bypass the automation entirely and trigger a forecast/schedule by hand with the same parameters, which drops the link to the automation (job trigger metadata, job stats on the automations tab).

Proposed behaviour

Add a way to trigger a single run of one existing automation, through all three interfaces:

• CLI: something like flexmeasures jobs run-automation --automation <id> (alongside the existing run-automations), printing the queued job ID(s).
• API: POST /api/v3_0/assets/<id>/automations/<automation_id>/trigger, mirroring the existing POST /assets/<id>/schedules/trigger in shape, and returning the queued job information (as run_automation already returns {"job_id": ..., "n_jobs": ...}).
• UI: a "Run now" action per automation on the asset's Automations tab, reporting the queued job so the user can follow it (the tab already shows per-automation job stats).

Under the hood this is a thin wrapper around run_automation() in flexmeasures/data/services/automations.py, so it stays a single code path with the scheduled runs.

Semantics to decide

• The cursor should not move. An on-demand run is extra work, not a claim on a scheduled occurrence, so it must not suppress the next scheduled run (nor swallow a missed one during catch-up). That also means the per-minute claim (claim_due_automation) is not the right guard here.
• Duplicate protection: the scheduled path uses a Redis guard keyed by automation-run:<id>:<scheduled_at>. An on-demand run needs its own answer: either no guard (the operator asked for it, and forecast/schedule jobs are already deduplicated per sensor by the job cache), or a short cooldown against double-clicks. Simplest first: no guard, and rely on the existing job deduplication.
• Inactive automations: an inactive automation is exactly the one you want to test before switching it on, so triggering one should be allowed - possibly behind an explicit confirmation in the UI.
• Permissions: running an automation writes data, so require update on the automation (i.e. what editing it requires) rather than read.
• Run records: if Add durable automation-run records and safe retry semantics #2393 lands first, an on-demand run should get its own run record, marked as manually triggered, so it shows up in the run history without being mistaken for a scheduled occurrence.

Acceptance criteria

• One automation can be run on demand from the CLI, the API, and the UI.
• The run uses the automation's stored parameters and data generator, and its jobs carry the same automation trigger metadata as scheduled runs, so they show up in the automation's job stats.
• Triggering a run does not advance the cursor, and does not affect which occurrences the scheduled runner considers due.
• Triggering is permission-checked, and rejected with a clear message for an automation the user may not run, an unknown automation, or one whose type cannot be run yet.
• Tests cover: a successful on-demand run of an active automation, an inactive one, the cursor staying put (and the next scheduled run still happening), and the permission checks.
• Documented in documentation/features/automations.rst and in the changelog.

Related

• Automations v1 #2334 (Automations umbrella), Automations - first roundtrip for forecasts #2288 (first roundtrip), Add per-automation timezones and catch-up semantics #2392 (timezones and catch-up)
• Add durable automation-run records and safe retry semantics #2393 (durable automation-run records and safe retry semantics) - a manual re-run is the operator-facing counterpart of the retry semantics described there
• Run reports via CLI and API #2298 (Run reports via CLI and API) - same idea, for reports specifically