Editing and saving data dependency (like `include_bytes!`) doesn't trigger `cargo check`

To reproduce

1. cargo init --bin
2. Open this project in VSCode.
3. Create the file data in the root of the project, with the following contents:

   hello
   

   (no trailing newline)
4. Ctrl-S
5. Put the following in src/main.rs:

   trait MyTrait {}
   
   impl MyTrait for [u8; 5] {}
   
   fn main() {
       let _t: &dyn MyTrait = include_bytes!("../data");
   }
   

6. Ctrl-S, observe that rust-analyzer shows no errors.
7. Go back to the file data and edit it, changing its length.
8. Ctrl-S, observe that rust-analyzer shows no errors.
9. Go back to file src/main.rs.
10. Ctrl-S, observe that rust-analyzer shows an error belatedly ("the trait bound [u8; 6]: MyTrait is not satisfied").

In the perfect world, the error would be displayed on step 8, immediately after editing and saving the data file.

This is an artificial minimal example.
For a motivating real-world example, consider a compile-time templating system like Askama. Askama uses derive proc macro to process template files, and emits include_bytes!() as a way to let the build system know about the data dependency. Mistakes in the template can result in compile errors. It would be nice if such errors were reported immediately on save, without having to manually trigger cargo check.

Version info

rust-analyzer version: 0.4.1296-standalone (26562973b 2022-11-20)
VSCode version: 1.71.1
cargo 1.66.0-nightly (73ba3f35e 2022-09-18)
rustc 1.66.0-nightly (3f83906b3 2022-09-24)

Reproduce the behavior with src/main.rs and the root data file using the listed VSCode and rust-analyzer steps, then compare diagnostics after saving data with running cargo check. Trace how the include_bytes!("../data") dependency is observed and determine what behavior would make the error appear immediately after the data file changes.