🐛 fix(governor): expose ACMM schedule changes

[Danathar]

Summary

Applying an ACMM level can change the governor's evaluation interval and multiple per-agent cadences. Before this PR, those scheduling changes were applied and persisted without being surfaced in the API response, dashboard, or logs. An operator could therefore select a level successfully and only discover the new schedule later—potentially after a governor restart activates a different ticker.

This PR makes those mutations explicit. It reports exact before/after values from both pack-apply APIs, shows them immediately in the dashboard, and emits a structured warning for operators diagnosing the change later.

Fixes #4711.

Problem

ACMM pack application reconciles more than the agent roster. On a first apply, expansion, or forced governor apply, it can also replace:

• governor.eval_interval_s
• per-mode, per-agent cadence values such as surge / scanner: pause -> 5m

The existing response described created, updated, paused, resumed, skipped, and tombstoned agents, but omitted governor scheduling changes. That made an important operational side effect invisible at the moment the operator caused it.

The distinction matters because the configuration is persisted immediately while a running governor can retain its current ticker until restart. Without before/after reporting, an apparently routine level change could produce a surprising schedule later.

What changed

API result

ApplyPackResult now includes an optional governor_changes object containing:

• an evaluation-interval change with exact from and to values;
• a deterministic list of cadence changes with mode, agent, from, and to values.

The field is omitted from the internal result when nothing changed. Both operator-facing endpoints return it:

• POST /api/packs/{level}/apply
• the ACMM level-setting endpoint

Only real mutations are reported. Reapplying an already-matching value does not create noise, unknown old cadence values are represented as unset, and cadence entries are sorted by mode and agent so API responses and logs remain stable.

Dashboard feedback

Both ACMM apply flows now:

• mark the success toast as a governor-settings change when applicable;
• display an alert containing each exact interval and cadence transition;
• keep the existing concise success path when the pack did not alter governor scheduling.

This gives the operator the information at the point of action instead of requiring a later config diff.

Operational logging

When scheduling changes occur, the server emits a structured WARN event named ACMM pack changed governor settings. The log includes the hive, level, pack name, interval transition, and cadence transitions, providing an audit trail without logging routine no-op applies.

Behaviour and scope

This is an observability fix, not a change to ACMM reconciliation policy:

• governor values are still updated under the same first-apply/expansion/forced-apply conditions;
• pack thresholds, stale timeouts, roster reconciliation, and persistence behaviour are unchanged;
• this does not restart the governor or alter when a persisted interval takes effect;
• no new endpoint, permission, or configuration field is introduced.

Verification

• env GOCACHE=/tmp/hive-go-build-4711 CC=/usr/bin/gcc CXX=/usr/bin/g++ go test ./pkg/dashboard -count=1
• Regression coverage verifies exact evaluation-interval and cadence transitions from a forced L5 apply.
• Regression coverage verifies the structured warning contains the scheduling change.
• HTTP-level coverage verifies the pack-apply response includes governor_changes with the original value.

Files of interest

• src/pkg/dashboard/api_packs.go — captures, sorts, returns, and logs changes.
• src/pkg/dashboard/static/index.html — formats and displays the changes.
• src/pkg/dashboard/api_packs_governor_changes_test.go — locks the API and log behaviour.
• CHANGELOG.md — records the operator-visible fix.

— hive: backend=codex

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign clubanderson for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Danathar]

/cc @clubanderson