Summary

Expose the config revision currently accepted by the running Gateway so clients can distinguish saved config from applied runtime state.

Problem to solve

Control UI config pages auto-save through config.set and show a Restart & apply banner. The Gateway currently exposes the saved config hash, but not the revision loaded by the active process. Browser-local state therefore cannot tell whether an out-of-band restart already applied the file, and it cannot truthfully reconstruct the banner after reload.

Proposed solution

Add an optional appliedConfigHash to the hello snapshot and config.get. Derive it from the resolved source config accepted at startup or after successful hot/no-op application. Also return a resolved current configRevisionHash; keep the existing raw root-file hash for optimistic write guards. Control UI compares current and applied revision hashes.

Alternatives considered

• Keep a pending hash in localStorage: survives a page reload, but remains stale after an out-of-band Gateway restart.
• Compare only the raw root-file hash: misses changes made through $include files.
• Bump the protocol version: unnecessary for optional additive fields.

Impact

Affected: Control UI users editing Gateway config.

Severity: Medium; the current banner can claim a restart is needed when it is not, or lose truthful state across browser/runtime lifecycles.

Frequency: Every auto-saved config edit and subsequent page or Gateway restart.

Consequence: Unnecessary restarts and ambiguous applied state.

Evidence/examples

ui/src/lib/config/index.ts currently owns the banner state, while the Gateway config snapshot only identifies the saved file revision.

Additional information

The protocol change must remain additive. No protocol version bump without owner confirmation.