fix: distinguish secrecy vs integrity in filtered notice

[Copilot]

Fixes the integrity filtering problems reported in #2502.

Problem

The buildDIFCFilteredNotice function used "integrity policy" as a blanket term for all filtering — even when items were blocked for secrecy reasons. This caused the audit detection pipeline to:

1. Label secrecy blocks as "Integrity filter blocked" (wrong type)
2. Report "don't meet the GitHub integrity level" (wrong dimension)
3. Suggest "lower min-integrity" as the fix — which has no effect on secrecy restrictions

The root issue is that FilteredItemDetail only stored a Reason string, losing the structured information about why an item was filtered (secrecy vs. integrity).

Changes

File	Change
internal/difc/resource.go	Add IsSecrecyViolation bool to FilteredItemDetail
internal/difc/evaluator.go	Set IsSecrecyViolation in FilterCollection based on result.SecrecyToAdd
internal/server/difc_log.go	Add difcPolicyLabel helper; update buildDIFCFilteredNotice to use "secrecy policy" / "integrity policy" / "access policy"; replace internal [DIFC] prefix with user-friendly [Filtered]
internal/server/difc_log_test.go	Add TestBuildDIFCFilteredNotice_{SecrecyViolation,IntegrityViolation,MixedViolations} and TestDifcPolicyLabel
internal/difc/evaluator_test.go	Add IsSecrecyViolation assertions to existing FilteredItemsHaveReasons tests

Example — before vs after

Before (all filtering labelled as integrity, internal term exposed):

[DIFC] 2 item(s) in this response were removed by integrity policy and are not shown:
resource:actions_get (has secrecy requirements that agent doesn't meet ...);
resource:get_job_logs (has secrecy requirements that agent doesn't meet ...)

After (correct label for secrecy blocking, user-friendly prefix):

[Filtered] 2 item(s) in this response were removed by secrecy policy and are not shown:
resource:actions_get (has secrecy requirements that agent doesn't meet ...);
resource:get_job_logs (has secrecy requirements that agent doesn't meet ...)

With this fix, downstream consumers (the audit detection pipeline, agents, operators) can accurately identify the type of violation and receive correct remediation guidance — without exposure to internal implementation terminology.

---

⌨️ Start Copilot coding agent tasks without leaving your editor — available in VS Code, Visual Studio, JetBrains IDEs and Eclipse.

[lpcox]

@copilot we should not expose the term DIFC to users.

[Copilot]

@copilot we should not expose the term DIFC to users.

Done in 8ecdf2c. Replaced the user-facing [DIFC] prefix with [Filtered] and "DIFC policy" with "access policy" in the notice text. Internal log entries (file/stderr) still use [DIFC-FILTERED] since those are for operators, not end-users.

[Copilot]

Pull request overview

This PR fixes DIFC filtered notices so they correctly distinguish secrecy vs integrity filtering (and uses a neutral “access policy” label when both occur), improving downstream audit/detection guidance and avoiding misleading remediation suggestions.

Changes:

• Add IsSecrecyViolation to difc.FilteredItemDetail and set it during Evaluator.FilterCollection.
• Update buildDIFCFilteredNotice to use a new difcPolicyLabel helper and change the user-visible prefix from [DIFC] to [Filtered].
• Extend tests to assert IsSecrecyViolation behavior and validate notice labeling for secrecy, integrity, and mixed cases.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
internal/difc/resource.go	Extends FilteredItemDetail with IsSecrecyViolation to preserve filtering dimension.
internal/difc/evaluator.go	Populates IsSecrecyViolation based on whether the denial was due to secrecy (SecrecyToAdd).
internal/server/difc_log.go	Updates filtered notice text/prefix and adds difcPolicyLabel to select secrecy/integrity/access wording.
internal/server/difc_log_test.go	Updates existing notice prefix assertions and adds new tests for secrecy/integrity/mixed labeling.
internal/difc/evaluator_test.go	Adds assertions ensuring filtered items correctly set IsSecrecyViolation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

newTestFilteredItem sets IsSecrecyViolation based on whether secrecyTags is non-empty, but in the main codepath (Evaluator.FilterCollection) the flag is set based on whether a secrecy violation occurred (len(result.SecrecyToAdd) > 0). An item can legitimately have secrecy tags while being filtered for integrity reasons (or have secrecy-related reason text without tags in these tests), so this inference can produce incorrect IsSecrecyViolation values and make tests brittle/misleading. Consider either (a) passing an explicit isSecrecyViolation parameter to the helper, (b) deriving it from the same condition the production code uses for filtered items in these tests, or (c) leaving it unset in helpers that aren’t specifically constructing filtered-by-secrecy cases.