fix: Stale diagnostics with rust-project.json and rustc JSON

[Wilfred]

PR #18043 changed flycheck to be scoped to the relevant package. This broke projects using check commands that invoke rustc directly, because diagnostic JSON from rustc doesn't contain the package ID.

This was visible in the rust-analyzer logs when RA_LOG is set to rust_analyzer::flycheck=trace.

Before:

2026-02-02T07:03:48.020184937-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Workspace
...
2026-02-02T07:03:55.082046488-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Workspace

After:

2026-02-02T07:14:32.760707785-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) }
...
2026-02-02T07:14:48.355981415-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) }

Previously r-a assumed that a diagnostic without a package ID applied to the whole workspace. We would insert the diagnostic at the workspace level, but then only clear diagnostics for the package.

As a result, red squiggles would get 'stuck'. Users who had fixed compilation issues would still see the old red squiggles until they introduced a new compilation error.

Instead, always apply diagnostics to the current package if flycheck is scoped to a package and the diagnostic doesn't specify a package. This makes CargoCheckEvent(None) and CargoCheckEvent(Some(_)) more consistent, as they now both match on scope.

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 2cefe47

[Wilfred]

I spent a while trying to find a nice way to write a unit test for this but didn't succeed. I have tested an r-a build manually for both cargo and non-cargo projects though.

[Veykril]

That explains the issue i was observing when i was checking out buck2 a couple weeks ago, nice!

Thanks!

[Veykril]

I think this regressed things, for cargo, diagnostics for crates only clear once the check is complete (if it doesn't produce diagnostics) instead of clearing when the respective crate has finished checking.

[Veykril]

Yea in fact I think we cannot use the scope variable to determine how to add diagnostics (whether to associate them with a package or the workspace), that var can change depending on how one triggers flychecking which may cause stale diagnostics. I'll revert this PR for now.