fix(mcp): don't stamp no_recent_changes when RBAC hid correlated evidence

[nadaverell]

Problem

Found while auditing the #1300/#1302 RBAC work for drop-vs-degrade behavior. Per-issue change correlation (internal/mcp/issue_correlation.go) filters a workload issue's correlated changes by per-kind RBAC — a workload subject's candidates include its consumed ConfigMaps, which the caller may not be able to read (#1300). But when that filter empties the list, the code fell through to stamping the issue with an affirmative no_recent_changes marker.

The marker's own contract says otherwise — fetch errors and saturated fetches deliberately omit it ("marker omitted = unknown, never a false 'no changes'"). RBAC-hidden is the same epistemic state: evidence exists; this caller can't see it. The failure mode is concrete: a user with workload access but no ConfigMap access gets their crashing Deployment certified "no recent changes in the window — chronic issue" when its consumed ConfigMap rotated two minutes ago, and MCP consumers (including AI diagnosis) explicitly weigh that marker.

Fix

applyCorrelationVisibilityFilters applies the category filter first, then the RBAC filter, and reports whether RBAC removed a relevant row. When the visible set is empty, rbacHidden joins saturated in omitting the marker — unknown, not "no changes". Ordering matters: a status-churn row dropped by the category filter must not suppress the marker for a genuinely quiet subject.

CorrelatedChanges behavior is unchanged (still only rows the caller may read); auth-off is unchanged (no user → RBAC filter is a passthrough → rbacHidden is always false).

Tests

• TestApplyCorrelationVisibilityFilters_RBACHiddenIsNotNoChanges: unreadable ConfigMap as the only relevant change → empty + hidden (marker suppressed); readable Deployment + status-churn row → visible + not hidden (quiet subjects still earn the marker); auth-off passthrough.
• go build, go vet, full go test ./... green.

---

Note

Medium Risk
Changes triage marker semantics for MCP/issue consumers (including diagnosis), but scope is limited to the correlation visibility path and aligns with existing “omit = unknown” behavior for errors and saturation.

Overview
Fixes a false no_recent_changes stamp when per-kind RBAC removes correlated evidence (e.g. a consumed ConfigMap the caller cannot list) but the issue subject is still readable.

Correlation now runs applyCorrelationVisibilityFilters, which applies spec/lifecycle filtering first, then RBAC, and sets rbacHidden when relevant rows were dropped for permissions. If the visible set is empty, rbacHidden is treated like a saturated fetch: the marker is omitted (unknown), not an affirmative “nothing changed.” Status-only churn still does not count as hidden, so genuinely quiet subjects still get the marker.

Adds TestApplyCorrelationVisibilityFilters_RBACHiddenIsNotNoChanges for hidden ConfigMap, readable Deployment + status churn, and auth-off passthrough.

^{Reviewed by Cursor Bugbot for commit cd705f9. Bugbot is set up for automated code reviews on this repo. Configure here.}