note_suppressed_count's zero guard is untested: nothing pins that a clean call stays served

[plusky]

AuditCell::note_suppressed_count (crates/bugwarden/src/audit.rs) opens with:

pub fn note_suppressed_count(&self, n: u64) {
    if n == 0 {
        return;
    }
    ...
}

That guard is what stops a suppression-free call from merging Verdict::ServedFiltered and upgrading its own verdict. Every call site passes total - filtered.len(), which is 0 on the common path where nothing was filtered — so without the guard, every bug_comments, summarize_bug and list_attachments call would record served_filtered whether or not anything was withheld.

Deleting the guard leaves the entire test suite green (verified by mutation during the adversarial review of #86). Nothing asserts that a clean call records served.

Why it matters

verdict is the field an operator filters on to find calls where the guard actually did something. If every read tool reported served_filtered unconditionally, the distinction would collapse silently — the records would still validate, and suppressed_count: 0 beside served_filtered reads as a rounding artefact rather than a bug. It is the same class of silent-but-valid defect as #68 itself.

This is pre-existing behaviour and was correct before and after #86; only the coverage is missing.

Related gap

list_attachments's note_suppressed_count call site (server.rs:2723) also has no integration coverage — deleting it leaves the suite green too. #86 left it alone deliberately, since ids are always empty there so max == sum and no test would have been pinning that change. It is worth covering in the same pass as this.

Acceptance criteria

• A test asserts that a bug_comments call with nothing filtered records verdict: served and suppressed_count: 0, and fails if the n == 0 early return is removed.
• A test covers list_attachments's counter site, so deleting that call is detectable.

Found by mutation testing during the adversarial review of #86 (issue #68).