Gate system enrichment API by per-OpDiv insights flag

[danielbowne]

Summary

Gates the existing system enrichment read endpoint (GET /api/v1/systemenrichment/{fisma_uuid}) on a new per-OpDiv capability flag, so ZTMF Insights enrichment is served only for OpDivs that have an insights pipeline feeding them. Today that is CMS only; enabling another OpDiv later is a single database update, no code change.

Why

Enrichment data (system metadata from the ZTMF Insights pipeline) currently exists only for CMS, but the read endpoint returned a payload for any system that had a row, with no notion of which OpDivs are entitled to the feature. This adds that boundary and makes it data-driven so the feature can extend to other OpDivs as an add-on.

Changes

• Migration 0042: adds opdivs.insights_enabled (boolean, default false), backfills it true for the active CMS OpDiv. Down migration drops the column.
• Model: OpDiv.InsightsEnabled *bool (pointer so an update that omits it does not reset it), conditional set on save. FindSystemEnrichment returns a row only when the system's fismauid maps to an OpDiv with insights_enabled = TRUE (an EXISTS predicate, which avoids fanning out on the non-unique fismauid).
• Controller: resolves the system first, then authorizes against its OpDiv (CanAccessFismaSystem), replacing the prior per-system-only check. A system in a non-enabled OpDiv returns 404, identical to a system with no enrichment row, so the gate never reveals which systems exist.
• Tests: model integration test for the gate, plus an Emberfall E2E case proving a system with an enrichment row in a disabled OpDiv returns 404.
• OpenAPI regenerated from annotations.

Behavior and compatibility

• Backwards compatible. Additive schema change; deploys to dev on PR, prod on merge.
• Enrichment is only hidden for systems in OpDivs that are not insights-enabled. The pipeline only feeds CMS, and the migration enables CMS, so existing enrichment continues to be served unchanged.
• Minor authorization tightening: OpDiv-scoped admins now read enrichment only for systems in their granted OpDivs (previously any admin tier could read any system's enrichment). Unscoped admins (OWNER, HHS) and assigned ISSOs are unaffected.

Testing

Full local suite passes: unit, integration (including the new gate test), and E2E (Emberfall). Validated end to end against real enrichment data in the impl environment.

Issues

Implements CMS-Enterprise/ztmf-misc#85 (API endpoints for SDL enrichment data). The read surface landed in #211; this PR adds the OpDiv-conditional gate that completes the consumption API. The issue's original per-function response shape is superseded by the generic jsonb payload (the pipeline owns structure). It will be closed on merge (cross-repo keywords do not auto-close from this repository).

[MackOverflow]

clean, this can be done later (not an approval blocker) but 1 nit:

FindFismaSystemByUUID has no LIMIT 1 — the comment acknowledges fismauid is not schema-unique and says "first match is sufficient," but without a LIMIT the query could return multiple rows and fail at the queryRow scan level rather than deterministically returning the first. A LIMIT 1 would make the behavior explicit and avoid a potential runtime error if duplicates ever appear.
// backend/internal/model/fismasystems.go
sqlb := stmntBuilder.
Select(fismaSystemColumns...).
From("fismasystems").
Where("LOWER(fismauid) = LOWER(?)", fismaUUID).
Limit(1) // add this

Maybe we aren't making this explicit on purpose, but it does leave that limit open.

[MackOverflow]

clean