agent: add chrony supplementary group so it can read tracking.log (DAC)

The tracking.log read was still returning empty under enforcing with NO AVC —
the tell of a DAC (not SELinux) denial. Root cause: /var/log/chrony is mode
0750 chrony:chrony (others have no access), so the agent's DynamicUser (group
tss only) can't even traverse the directory to reach the 0644 tracking.log —
EACCES on open, which produces no audit record. Manager confirmed genuinely on
fleet-manager-1db3977 (chrony-capable), and uptime flowed while chrony didn't,
proving the agent was sending empty chrony (failed read), not a manager gap.
Earlier manual reads worked only as root (sudo) or because fleetadmin had been
usermod'd into chrony during the socket test (reverted on reboot — /etc/group
is on the volatile overlay).

Fix: SupplementaryGroups=tss chrony on the unit — the chrony group has r-x on
the 0750 dir so the agent can traverse it; the log file is world-readable. This
is the DAC half; the fleet_agent_chronylog SELinux module (02a6621) is the TE
half — BOTH are required (verified: group-only -> TE-denied; module-only ->
DAC-denied silently). Corrected the now-stale 'no group' code comment; recorded
the two-layer requirement in the .te and stig-deviations #16. Needs a
workstation image rebuild + reboot.

docs/stig-deviations.md

@@ -275,6 +275,15 @@ reach it. No write, no other chrony access, and — unlike the earlier abandoned
 approach — **no domain transition** (the agent reads a file; it does not exec
 `chronyc`). This replaces the never-shipped `fleet_agent_chronyc` nnp-transition
 module (that whole command-socket path was dropped for reading the log instead).
+
+**This is the SELinux half of a two-layer requirement.** `/var/log/chrony` is
+mode `0750 chrony:chrony` (others have no access), so DAC also blocks the agent's
+`DynamicUser` from traversing the dir — a denial that produces **no AVC** (it's
+DAC, not TE). The DAC half is therefore the **`chrony` supplementary group** on
+`fleet-agent.service` (traverse the `0750` dir; the log file itself is `0644`).
+Both this module and that group are needed; verified 2026-07-10 — with the group
+but no module the read is TE-denied, and with the module but no group it's
+DAC-denied (silently, no AVC — which is what made this the hardest layer to spot).
 **BENCH-VERIFY:** (a) the manager's Monitor chrony row populates on an enforcing
 boot; (b) no other chrony-log AVC (extend here if one appears); (c)
 **reproducibility** — `semodule -i` rebuilds the policy store, re-check verity hash