Add GE-Enforce observed-state reporting: receipt + self-heal from PCs

PCs now report enforcement results back to shopdb, closing the desired-vs-observed
loop.

- POST /api/geenforce/report (geenforce.report service token): each cycle a PC
  posts the published version it applied, install/skip/fail/filtered counts, and
  per-entry outcomes.
- Two tables: manifestenforcementreports (latest-per-host + history: applied
  version, enforcer version, counts, derived status ok/selfhealed/failed) and
  manifestenforcementresults (per entry: action installed/skipped/failed,
  selfhealed flag, exit code, warning/error message).
- RECEIVED: reports carry the applied version; the admin view derives
  receivedlatest by comparing it to the scope's current published version, so
  the fleet view shows which PCs picked up an update.
- SELF-HEAL: per-entry action captures drift correction (installed when it
  should already be present) vs skipped (already good) vs failed, with messages.
- Admin reads: GET /reports (fleet compliance rollup) and GET /reports/<id>
  (per-entry detail). New geenforce.report permission.
- Tables added to the (undeployed) 0001 baseline; geenforce.post_report is a
  service-token endpoint so it is exempt from the JWT authz sweep, like the
  collector blueprint. 8 reporting tests; full suite green.

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

docs/proposals/ge-enforce-plugin.md

@@ -339,13 +339,18 @@ PC-type manager:
   an immutable snapshot (see section 4) and is what the fleet then gets. Show the
   draft-vs-published diff before publishing. Rollback republishes a prior
   snapshot.
-- **Desired vs observed**: the scope page can show, per entry, how many fleet
-  PCs match the expected detection value. CAVEAT: this is NOT free with today's
-  collector - it reports `installedsoftware[]`, not the per-entry manifest
-  status map (`installedVersions` keyed `<scope>/<Name>` that GE-Enforce already
-  computes for status.json). Delivering this feature needs a new collector
-  payload field carrying that map. Worth it (it is the payoff of unifying
-  desired + observed state) but it is a dependency, not existing data.
+- **Desired vs observed (BUILT: observed-state reporting)**: rather than extend
+  the collector, the plugin has its own reporting path. Each enforcement cycle a
+  PC POSTs `POST /api/geenforce/report` (geenforce.report service token) with the
+  published version it applied, the installed/skipped/failed/filtered counts, and
+  per-entry outcomes. Stored in `manifestenforcementreports` (latest-per-host +
+  history) and `manifestenforcementresults` (per-entry). Two payoffs fall out:
+  RECEIVED - `receivedlatest` compares the applied version to the scope's current
+  published version, so the fleet view shows which PCs picked up an update; and
+  SELF-HEAL - each entry's action (installed = drift corrected, skipped = already
+  good, failed) with any warning/error message. Admin reads: `GET /reports`
+  (fleet compliance) and `GET /reports/<id>` (per-entry detail). This is the
+  observed half that makes the manifest a closed desired-vs-observed loop.
 
 This is an ADR-010 settings card contributed by the geenforce plugin, so it only
 appears when the plugin is enabled.