Add false-positive evidence facets to audit recipes

[Widthdom]

Latest dogfood scans showed several audit recipes are useful but too binary: they report the raw pattern without enough evidence to separate risky code from already-bounded or intentional code.

Examples:

• cancellation-token-none reports documented sync compatibility wrappers and timeout-cleanup continuations alongside real cancellation gaps.
• sync-over-async reports documented process-boundary bridges.
• broad-exception-catch mixes top-level command boundaries with swallowed diagnostic paths.
• raw-diagnostic-echo does not distinguish outputs already passed through DiagnosticRedactor / CommandErrorWriter.FormatSanitizedException.
• path-case-heuristic reports protocol tokens, CLI option names, and label/name comparisons in addition to path equality.
• process-start-info reports safe shared wrappers and direct launch sites with the same weight.
• full-materialization and max-value-probe report code with explicit size/saturation comments and bounds.
• authorization-handling reports SQL ALTER AUTHORIZATION references as auth-boundary hits.

Requested improvement: add recipe result facets, suppression hints, or query refinements that expose why a hit is risky versus likely-safe, e.g. bounded wrapper, top-level boundary, sanitizer present, protocol/non-path domain, safe process wrapper, or known saturation helper.

[Widthdom]

More false-positive / evidence-facet cases from dogfooding:

• Searching for catch with --match-origin code still matches identifiers such as EmitCatchTypeReferences; a syntax-aware facet for actual catch blocks would make exception audits much cleaner.
• The authorization-handling recipe picks up SQL ALTER AUTHORIZATION extraction code, which is unrelated to HTTP/auth header handling.
• Recipe output would benefit from facets that explain why a match is considered auth-boundary code vs language/parser code.

This is the same broad feature need: audit recipes should expose enough classification evidence to separate likely findings from structural/parser false positives.

[Widthdom]

More dogfood cases that fit this issue:

• broad-exception-catch currently mixes top-level command/MCP boundaries with swallowed diagnostic/recovery paths.
• process-start-info reports direct launch sites, shared wrappers, and wrapper helpers with the same weight; it would help to facet UseShellExecute, cwd, environment mutation, and ArgumentList setup.
• authorization-handling reports SQL ALTER AUTHORIZATION reference extractor patterns as auth-boundary hits.
• full-materialization / ad hoc ToArray() hits mix safe byte-literal constants, cached language lists, MCP diagnostic arrays, suggestion evidence arrays, and potentially unbounded materialization.
• A regression recipe for TaskCompletionSource without RunContinuationsAsynchronously would benefit from the same positive-evidence facet because current hits appear to be safe.

The common need is a risk facet that separates already-bounded or intentional patterns from likely actionable findings.

[Widthdom]

Additional false-positive facet candidates from the next audit batch:

• risky-code/full-materialization reports bounded byte-array decoding helpers such as ProgramRunner.DecodeWorkspaceVersionPinBytes and DataDirectorySecurity.DecodeText; the recipe should indicate whether bytes were already capped before materialization.
• risky-code/raw-diagnostic-echo mixes raw ex.Message paths with messages already shaped through DiagnosticRedactor, CommandErrorWriter.FormatSanitizedException, or dedicated formatting helpers.
• risky-code/path-case-heuristic still returns protocol/name/comparer code alongside real filesystem path equality cases.
• risky-code/max-value-probe reports safe saturation and limit helpers such as SaturatingAdd, EstimateJsonUtf8Bytes, MCP fetch limits, and bounded stream counters alongside actual unbounded int.MaxValue probes.
• File.ReadAllText / File.ReadAllBytes searches show helper-positive cases (ConsoleUi.PrintExamples, FileContentLoader.ReadRawBytesWithSizeLimit) that should be recognized as bounded or source-safe.
• StringBuilder searches show many deliberately bounded types (BoundedTextWriter, BoundedLineReader, WorkerOutputBuffer, GlobalToolLog, etc.); an unbounded-growth recipe should surface max-char evidence instead of reporting all builders equally.
• risky-code/http-client-construction reports GitHubHttpClientFactory.CreateDefaultHttpClient; shared factory construction should be a positive facet, not the same severity as ad hoc per-call construction.

The common request is a richer risk_evidence field so audit recipes can separate unsafe pattern matches from known bounded/helper/factory patterns.

[Widthdom]

Work started on branch fix-issue3929-3967-3919-3920-3979-3923.