feat(rolldown): add rule-based build scan with CI gating #624

Clear and concise description of the problem

DevTools for Rolldown already surfaces the data needed to investigate a build: duplicate packages, plugin hook costs, module and chunk graphs, assets, and session comparison. What it does not have is a way to encode what is wrong and enforce it. Every review is manual — open the UI, check the Packages → Duplicated tab, scan plugin timings, compare sessions — and nothing can fail CI.

Rsdoctor has this as a dedicated layer over compiler data ("build scan"): rules with severity and ignore/threshold config, built-in checks (duplicate packages, cross-chunk packages, loader/plugin time thresholds, ECMA target, default imports, mixed initial/async modules, side-effects-only tree shaking, CJS require, ESM resolved to CJS), custom rules, and findings in both the CLI and the report: https://rsdoctor.rs/guide/rules/rules.md

Today the equivalent information exists in the DevTools panels, but it is only consumable by a human looking at it.

Suggested solution

Add a checks layer to @vitejs/devtools-rolldown, evaluated over the recorded @rolldown/debug session data:

• Built-in checks for the classes above where the data exists: duplicate package versions, cross-chunk duplicates, plugin hook time budgets, modules present in both initial and async chunks, etc.
• A checks config with off | warn | error, ignore patterns and thresholds, in the shape users already know from linter configs.
• Findings in the DevTools UI and the static report, reusing the existing diagnostics/messages surfaces.
• vite-devtools check (or a flag on vite-devtools build) that prints a summary and exits non-zero when error-level findings exist, so CI can gate on it.

The session data is already recorded for the existing panels, so the checks can be pure functions over a session. bundleAnalyzerPlugin's JSON could feed the same checks for non-Vite users later.

Alternative

Expose a stable read API for recorded build sessions and let a community plugin implement the rules. A rule engine outside core would still need a CLI entry point to be usable in CI.

Additional context

• Rsdoctor built-in rules: https://rsdoctor.rs/guide/rules/rules.md
• Related: Compare module sizes between build sessions #601 / feat(rolldown): add modules to session compare #615 add module-level session compare, feat: agent support #611 adds agent access. Once the agent surface lands, the same findings could be exposed through it.
• For reference, bundleAnalyzerPlugin already emits an LLM-oriented Markdown report (https://github.com/rolldown/rolldown/blob/main/docs/builtin-plugins/bundle-analyzer.md), but it reports facts, not pass/fail checks.

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.