Add manifest revision history + draft audit trail to GE-Enforce plan

- Every publish is a permanent immutable revision (manifestpublishedversions),
  kept indefinitely; optional retention policy (keep last M / prune older than N)
  deferred, default keep-everything.
- Draft edits are not versioned (working copy overwrites), so field-level "who
  changed what between publishes" rides the existing core audit system - no new
  table, shows in the Audit Logs UI IT already uses.
- Runbook: History tab for published versions + roll back; Audit Logs for draft
  edit provenance.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/proposals/ge-enforce-plugin.md

@@ -183,6 +183,20 @@ average site IT tech maintaining it, not a specialist.
   snapshot, never the live draft. Rollback = flip `iscurrent` to an older
   version (the post-cutover safety net once the on-share JSON is retired).
   Mirrors today's `_meta/history/<date>-<scope>.json` backups, but authoritative.
+  Revision history: every publish is a permanent, immutable revision kept
+  indefinitely (snapshots are small JSON text, ~10 scopes - storage is a
+  non-issue). An OPTIONAL retention policy (keep last M per scope, or prune
+  older than N months) can be added later; default is keep-everything, off.
+
+- Draft-edit audit trail (field-level history BETWEEN publishes): drafts
+  (`manifestentries`) are not versioned - editing overwrites the working copy.
+  To answer "who changed this entry and when" in the window between two
+  published revisions, log every draft mutation through the EXISTING core audit
+  system (no new table): on create/update/delete of a scope, entry, or child
+  row, write an audit record with the actor, timestamp, entry name, and the
+  changed field(s). This gives per-edit provenance for free and shows up in the
+  same Audit Logs UI IT already uses; the published snapshots remain the
+  coarse-grained "what the fleet actually got" record.
 
 - `manifestentrypctypes`, `manifestentryhostnames`, `manifestentrymachinenumbers`
   - child rows for the ANDed multi-value filters (one value + a `sortorder` per
@@ -623,3 +637,7 @@ All in Settings > Imaging PC Types. No PowerShell, no SQL, no share edits.
   when happy, remove the filter and Publish again.
 - **Check "did PC Y get app X":** the simulator with that PC's type/machine
   number/CMM version shows exactly which entries apply and why others are filtered.
+- **See revision history / who changed what:** the PC type's History tab lists
+  every published version (date, author, note) with a Roll Back on each; the
+  Audit Logs page shows the finer-grained draft edits (who touched which entry
+  field, when) between publishes.