build(deps): adopt Kensa v0.8.0

[remyluslosius]

What

Adopts Kensa v0.8.0. This is v0.7 exit criterion 6, and it was deliberately blocked on the outcome vocabulary (#761) until now.

Bumping before #761 landed would have written audit rules to hardened RHEL hosts while telling the operator "No host change was committed" and refusing rollback. Verified reachable on 2 of 6 reachable dev-fleet hosts.

Payload

The frozen api/ change is additive and already handled by #761. Everything else is corpus-side:

Change	Effect
STIG Ubuntu coverage	~6% to 84.0% (22.04) and 85.6% (24.04)
CIS Ubuntu	41.8% (22.04), 38.9% (24.04), campaign in progress
Corpus	748 to 769 unique rule ids
config_value dropin_dir	pwquality read only the base file and false-FAILED a host hardened via pwquality.conf.d/, which is where CIS/STIG remediation writes
Exact audit-rule matching	-F path=/usr/bin/su no longer substring-matches a loaded /usr/bin/sudo, which was a false-PASS on the su control
audit_rule_set staging	Stages reboot-deferred on immutable-audit hosts instead of failing. This is the change #761 exists to handle
golang.org/x/text	v0.38.0 to v0.39.0 (GO-2026-5970)

The guard was checked, not assumed

remediation.OutcomeOf maps every TransactionStatus v0.8.0 can produce, verified by running AC-11 against the real module. Nothing falls through to the fail-closed branch.

That is the guard working as intended: a Kensa bump that introduced an unmapped terminal status would now fail the build here rather than mis-report a mutated host.

Expect score movement on the first scan

The verdict corrections are strictly more correct, but they do change shipped RHEL cis/stig results:

• drop-in reads now see values set in *.conf.d/
• maxrepeat / maxsequence now fail an explicit =0 (previously a false-PASS; =0 disables the check)
• framework-divergent thresholds default to the stricter requirement (pwquality difok: CIS >= 2 vs STIG >= 8, ships 8). A CIS-only operator loosens with --var.

Hosts will flip state and drift alerts will fire. That is the corpus becoming honest, not a regression — but it is visible, and worth saying before someone opens a dashboard.

Doc counts

Applied the BACKLOG DOC-2 rule that a bare number is the bug. Every count now names its scope and version ("769 rules in the corpus, Kensa v0.8.0"), and the guides state explicitly that a single host is measured against the subset applying to its OS, not all 769.

That ambiguity is exactly what put three different rule counts into circulation (508, 539, 748) across the repo and the Context Plane.

Packaging

kensa-rules needs no manual bump: build-kensa-rules.sh derives its version from the module via stage-kensa-rules.sh. Verified resolving to 0.8.0 / 769 rules.

SDD

system-kensa-executor 2.7.0 -> 2.8.0 (AC-10 version pin). 116 specs, 116 passing.

Verification

gofmt, go vet, go build ./..., full go test ./internal/..., spec gate.