Enriched feed: config revision + last-change provenance so the stack can detect changes made directly on the rig

[VijitSingh97]

Context

pithead#185 (Worker Inspect) keeps a per-worker config-change history on the Pithead side (RigForge keeps none on the rig, which is fine and intended). One of its acceptance criteria was to log the source of each change — "edited from the dashboard" vs "changed externally on the rig." Pithead can record its own dashboard-applied changes, but it currently has no way to detect a config change made directly on the rig (a local rigforge.sh apply, a hand-edit + apply, an autotune-driven change).

The gap

• The control API's GET :control_port/status (_control_status(), rigforge.sh:3646) reports only the most recent change's outcome, and only for changes that went through the control path (source: "control"). A change applied locally on the rig writes no control status at all.
• The enriched feed carries no config revision/generation marker, so a polling consumer can't tell "this rig's config is the same as last time I looked" from "it changed under me."

Net: Pithead can't honestly show "changed on rig since you last edited it," and can't invalidate its prefill when the rig diverges.

The ask (proposed shape)

Expose a cheap config revision + last-change provenance in the enriched feed, updated whenever config.json is (re)written by any path (control-apply, local apply, autotune, restore):

"rigforge": {
  ...,
  "config_meta": {
    "revision": 7,                       // monotonic counter, or a content hash of the writable config
    "changed_at": "2026-07-12T04:10:00Z",
    "source": "control" | "local" | "autotune" | "restore",
    "last_change_id": "<16hex>|null"     // the control change_id when source=="control", else null
  }
}

• revision is the load-bearing field: a consumer polling the feed compares it to the last value it saw. A bump it didn't cause = an external change → invalidate the prefill, surface "changed on rig."
• A content hash of the writable config is an acceptable alternative to a counter (stateless, survives restarts without a persisted counter) — your call; the consumer only needs "did it change."
• source/last_change_id let the dashboard attribute the change (dashboard edit vs local/autotune) without guessing.

Alternatively (or additionally), fold revision/source into the rigforge.config block proposed in the sister issue — one block is fine. The important thing is a stable "has the effective writable config changed, and who changed it" signal on the read feed.

Acceptance criteria

• The enriched feed exposes a config revision (counter or hash of the writable config) that changes iff the effective writable config changes.
• It exposes the source of the last change (control/local/autotune/restore) and the control change_id when applicable.
• Updated on every path that rewrites config.json, not just the control path.

Consumer reference

Pithead consumer: pithead#185 (the "changed on rig" provenance AC). Pairs with the effective-writable-config issue (same feed). Lets the dashboard distinguish its own edits from external ones and keep its editor prefill honest.