Curtailment: Response profiles and automation rules

[negarn]

Alignment note

This issue remains the broader product/settings scope for reusable curtailment response profiles and automation rules. The immediate MQTT source settings API/runtime reload work is tracked separately by #405 and draft PR #409; that work should not close this issue.

Current codebase alignment:

• Manual curtailment exists through the /energy flow.
• Curtailment supports FIXED_KW and FULL_FLEET reduction.
• Public manual preview/start/stop calls require org-scoped curtailment:manage.
• MQTT continuous-state ingest exists in fleetd, and Curtailment: Add MQTT source settings API and runtime reload #405/Curtailment: Add MQTT source CRUD, runtime, and connection test API #409 is adding operator-managed MQTT source configuration.
• There is not yet a CRUD API or UI for reusable response profiles or automation rules.

Context

We need a settings/curtailment area that lets operators configure reusable curtailment response profiles and automation rules that apply those profiles when configured conditions are met.

Example workflow: an operator creates an Emergency curtailment response profile that sheds the full load across all miners in the fleet. The operator then creates an automation rule that watches for a condition, such as an emergency response obligation or other triggering signal, and applies the Emergency curtailment profile when that condition is met.

Requirements

• Add a settings/curtailment page or equivalent settings entry point for curtailment configuration. If the /energy page keeps an “Edit settings” entry point near the plan-curtailment action, it should route to this area.
• Allow users to create and edit response profiles.
• A response profile should represent the curtailment action to apply, such as full fleet shed, partial reduction, target power limit, site scope, miner selection strategy, and restore behavior as supported by the domain model.
• Allow users to create and edit automation rules.
• An automation rule should define a triggering condition and select the response profile to apply when that condition is met.
• Allow users to enable or disable each automation rule without deleting it.
• Allow users to reorder automation rules in the table/list so ordering can represent priority when more than one trigger is active at the same time.
• Make the priority behavior explicit in the product/API behavior, especially when multiple enabled rules match concurrently.
• Support editing existing profiles and rules without losing their relationship to existing automations.
• Profile/rule CRUD, enablement, disablement, and ordering should require org-scoped curtailment:manage.
• Rule execution by trusted automation should not be blocked by a public handler user-auth gate.
• Leave room for UI details to change as the product shape is refined.

Out of scope

• Tactical MQTT source settings API, enable/disable toggle, credential writes, source status, and runtime reload; tracked by Curtailment: Add MQTT source settings API and runtime reload #405 / PR Curtailment: Add MQTT source CRUD, runtime, and connection test API #409.
• First-class site-scope backend support; tracked by Curtailment: Add first-class site scope #404.
• Full-fleet all-skipped safety behavior; tracked by Curtailment: Distinguish empty scope from all-skipped FULL_FLEET #394.
• Public manual curtailment authorization hardening; tracked by Curtailment: Gate public curtailment operations #392 / PR Curtailment: gate public preview, start, and stop operations #408.
• Batched curtail dispatch and grouped activity detail; tracked by Curtailment: Batch dispatch and group command activity #403 / PR Curtailment: capture full cycle activity detail #406.

Acceptance criteria

• Users with org-scoped curtailment:manage can create, view, edit, and persist curtailment response profiles.
• Users with org-scoped curtailment:manage can create, view, edit, enable/disable, reorder, and persist curtailment automation rules.
• Each automation rule can be associated with a response profile that is applied when the rule condition is met.
• Rule ordering is persisted and used as priority when concurrent triggers need precedence.
• Editing an existing response profile or automation rule preserves relationships to existing automations unless the user explicitly changes them.
• The implementation includes appropriate client/server validation and targeted tests for profile CRUD, rule CRUD, enablement, ordering, priority behavior, permission gates, and response profile association.