Backlog: evaluate report surface for non-counting auth signals

[stacknil]

Context

LogLens reports findings, event counts, parser quality, warnings, host summaries, and finding explainability fields. The signal layer also contains evidence that is intentionally not counted by current rules.

With privilege auth failure signals now represented as non-counting AuthSignal values, there is a natural product question: should reports expose a compact inventory of non-counting signals, or should these remain an internal detector boundary unless they become part of a rule?

Implementation surfaces related to this boundary:

• src/signal.hpp
• src/signal.cpp
• src/report.cpp
• docs/report-artifacts.md

Short-term stance

Do not expand report.json, report.md, or CSV outputs just to list every non-counting auth signal in the immediate term.

Decision question

What is the smallest useful report surface for context-only signals such as SudoAuthFailure, SudoPolicyDenied, and SuAuthFailure?

Possible directions later:

• no report change; keep them internal signal-layer context
• aggregate counts by signal kind
• per-host or per-user non-counting signal summaries
• optional debug/audit section gated by a CLI flag

Why not now

The current report schema is already carrying parser quality, finding explainability, warning categories, and deterministic evidence IDs. Adding another signal inventory without a clear consumer could make the report noisier while weakening the existing review path.

The conservative current behavior is acceptable: these records can be parsed and tested without implying they are finding evidence.

Future acceptance bar

Before implementation, require:

• a concrete reviewer workflow that uses the extra surface
• golden report-contract fixtures for Markdown, JSON, and any CSV change
• compatibility notes for schema consumers
• docs explaining why non-counting signals do not affect findings
• tests proving unsupported parser warnings remain separate from non-counting parsed signals

Non-goals

• No hidden detector evidence
• No schema churn without a reviewer-facing reason
• No automatic severity or risk scoring