feat(health): catch credentials inline in committed systemd units #5618

From a live incident on the Vapron platform (2026-08-28), reported with the mechanism: systemctl show <unit> -p Environment printed four real credentials to an unprivileged account. Not a permissions bug — systemd publishes Environment= over D-Bus and systemctl show is unprivileged, so chmod does nothing. The fix is EnvironmentFile=, which D-Bus exposes as a path.

Checked our own surfaces first — clean, measured

• Host units: no gluecron/coolify unit carries inline Environment= at all (verified with keys-only output so no value could enter a transcript).
• Repo: the only Environment= we generate is BUILD_SHA/BUILD_TIME in the dormant self-deploy path.

What a repo scanner can honestly reach

The committed subset. Customers commit unit files; .service wasn't even in the eligible extension set; and no existing rule matched Environment="KEY=value" — the credential word sits before the inner =, with the quote ahead of it, which none of the generic patterns fit.

New critical rule with the D-Bus reason in its message, so the finding teaches the fix. The scope note says plainly that a unit edited live on a box is invisible here by construction — claiming runtime coverage would be the lie this module keeps un-learning.

Honesty stack applies

${VAR} substitutions and <your-token-here> placeholders cleared, build metadata doesn't match, EnvironmentFile= never fires, prose scoped out via NOT_PROSE — asserted with a full-length example value after the first draft of that test passed only because ... was under the length floor.

Verification

• 8 tests. Pre-flight: 0 findings from both deployed scanners. Full suite: 5,483 pass / 11 fail — baseline.