rustfmt with overrideCommand gets invoked with incorrect relative paths in complex projects

When setting rust-analyzer.rustfmt.overrideCommand to a non-absolute path, in complex projects rustfmt ends up getting invoked with an incorrect path and as a result LSP formatting no longer works.

For instance, the rust-lang/rust project requires the overrideCommand to be set to (relative to the checkout root) build/host/rustfmt/bin/rustfmt.
However, if the path is left at that, rust-analyzer will join it with its workspace root, which can be different from the checkout root.

From glancing at the sources, this line here is the culprit.

For instance, when editing a file under src/bootstrap, rust-analyzer appears to find the Cargo.toml in src/bootstrap as opposed to the one at the actual root. Trying to format the file then tries to run the command (..)/src/bootstrap/build/host/rustfmt/bin/rustfmt, which does not exist and thus the formatting fails.

Editors currently get around this by just setting an absolute path to the rustfmt binary directly.

This could be solved by an option similar to invocationStrategy for rustfmt, which would make the override command get joined with the overall root rather than the specific workspace root.

I could probably implement some fix for this myself, just wanted to ask for opinions from people involved here before trying to implement anything.

rust-analyzer version: rust-analyzer 1.83.0-nightly (12b26c1 2024-09-07)
rustc version: rustc 1.83.0-nightly (12b26c13f 2024-09-07)

Start in crates/rust-analyzer/src/handlers/request.rs around line 2211 and reproduce the issue in the rust-lang/rust project with rustfmt overrideCommand set to build/host/rustfmt/bin/rustfmt. Compare the workspace root with the checkout root while formatting a file under src/bootstrap. Done means a relative override command resolves from the intended overall root and LSP formatting succeeds.