fix(--format): some messages bypass format mode output even though they appear in humanReadable mode #23
Description
Description
When running the tool with --format, not all messages are emitted through the selected formatter, even though those messages do appear when using the humanReadable mode.
In other words, there is a mismatch between:
• what the tool outputs in humanReadable, and
• what actually goes through the --format rendering pipeline.
Expected behavior
• Every message/diagnostic that is displayed by the tool should go through a single, consistent reporting/rendering path.
• If --format <X> is enabled, 100% of the displayed messages must be rendered in format <X> (no raw / human-readable / mixed output).
Actual behavior
• Some messages are correctly rendered using --format.
• Other messages are output only in humanReadable (or raw text), even when --format is enabled.
Impact
• Inconsistent output, making it unreliable for CI and downstream parsing (JSON/SARIF, etc.).
• Confusing UX: mixed formatting in the same run.
• Structured output cannot be trusted to be complete.
Suspected cause / technical notes
• Some logs/diagnostics likely bypass the --format pipeline (e.g., direct stdout/stderr writes, logger calls outside the reporter, early error paths, CLI parsing errors, exception handlers, etc.).
• humanReadable seems to capture all events, while --format captures only a subset.
Acceptance criteria
• Identify which message paths bypass the formatter.
• Ensure all emitted messages go through a single reporting API (no direct printing).
• Add a regression test verifying that --format covers all displayed messages.
• Confirm humanReadable and --format consume the same underlying event stream.