Backlog: decide configurable semantics for privilege auth failure signals

[stacknil]

Context

The signal layer now has explicit non-counting signal kinds for privilege-adjacent authentication records:

• SudoAuthFailure
• SudoPolicyDenied
• SuAuthFailure

The current behavior is intentionally conservative: these records become AuthSignal entries, but all detector-counting flags remain false. They do not count as SSH attempt evidence, terminal authentication failures, or sudo-burst evidence.

Implementation reference:

• src/signal.hpp
• src/signal.cpp
• tests/test_detector.cpp

Short-term stance

Do not add configurable detector semantics for these privilege auth failure signals in the immediate PR train.

Decision question

Should sudo_auth_failure, sudo_policy_denied, and su_auth_failure eventually become configurable through auth_signal_mappings, or should they remain context-only signals unless a dedicated rule is introduced?

Why not now

The current detector contract is intentionally narrow:

• sudo_burst counts sudo_command only.
• SSH brute-force and multi-user probing are source-IP auth attempt rules.
• Privilege-denial events have different false-positive modes from SSH failures and privileged command bursts.

Promoting these signals too early would risk turning privilege policy context into detector confidence without a corpus-backed threshold model.

Future acceptance bar

Before implementation, require:

• sanitized fixtures for sudo password failures, sudoers denials, and failed su variants
• report-contract coverage showing whether these records affect findings or remain context-only
• rule-catalog updates describing grouping key, threshold, false-positive boundary, and rollback behavior
• compatibility notes for any config.json schema expansion

Non-goals

• No incident verdicts or attribution claims
• No live collection or response automation
• No offensive credential-testing workflow