Detect and surface relevant kernel warnings even when jobs pass

## Context

A user found a kernel WARNING in the full boot log of a job that KernelCI considered successful.

The current reporting flow creates log extracts primarily for failed builds or boot tests. As a result, a warning that the analyzer could recognize may not be surfaced when the overall job passes.

At the same time, successful boots may contain known or harmless warnings, so reporting every warning would create significant noise.

## Goal

Review how KernelCI analyzes successful jobs and determine how actionable kernel warnings can be surfaced without overwhelming developers with known or irrelevant messages.

Points to discuss
• Whether successful boot/test logs should always be analyzed.
• How known or non-actionable warnings should be handled.
• Ignore lists versus known-issue matching.
• Deduplication of equivalent warnings.
• What should cause a notification.
• How warnings should appear in the dashboard when the overall job still passes.

Start by tracing the reporting flow for successful jobs and how the analyzer handles full boot logs. Compare the options in the issue for filtering, matching, deduplicating, notifying, and displaying actionable warnings. Done means the project has an agreed approach for surfacing relevant warnings without reporting known or harmless noise.

Written by the indexing model from the issue text.