Overriding LTO option in global config.toml release profile causes bootstrap failure

This is on MSVC Windows 10, I'm unsure if that matters.

1. Have a global config.toml that overrides the release profile with lto = " fat" or lto = " thin"

So for example ~/.cargo/config.toml with

[profile.release]
lto = "thin"
... other settings that don't matter as much

3. Run x.py build
4. Wait for build failure

C:\Users\rsmyth\Documents\rust> python .\x.py build
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 2.11s
Building stage0 library artifacts (x86_64-pc-windows-msvc)
   Compiling compiler_builtins v0.1.109
   Compiling core v0.0.0 (C:\Users\rsmyth\Documents\rust\library\core)
   Compiling std v0.0.0 (C:\Users\rsmyth\Documents\rust\library\std)
   Compiling rustc-std-workspace-core v1.99.0 (C:\Users\rsmyth\Documents\rust\library\rustc-std-workspace-core)
   Compiling alloc v0.0.0 (C:\Users\rsmyth\Documents\rust\library\alloc)
   Compiling cfg-if v1.0.0
   Compiling rustc-demangle v0.1.24
   Compiling unwind v0.0.0 (C:\Users\rsmyth\Documents\rust\library\unwind)
   Compiling rustc-std-workspace-alloc v1.99.0 (C:\Users\rsmyth\Documents\rust\library\rustc-std-workspace-alloc)
   Compiling panic_unwind v0.0.0 (C:\Users\rsmyth\Documents\rust\library\panic_unwind)
   Compiling panic_abort v0.0.0 (C:\Users\rsmyth\Documents\rust\library\panic_abort)
   Compiling std_detect v0.1.5 (C:\Users\rsmyth\Documents\rust\library\stdarch\crates\std_detect)
   Compiling hashbrown v0.14.5
   Compiling rustc-std-workspace-std v1.99.0 (C:\Users\rsmyth\Documents\rust\library\rustc-std-workspace-std)
   Compiling proc_macro v0.0.0 (C:\Users\rsmyth\Documents\rust\library\proc_macro)
error: linker plugin based LTO is not supported together with `-C prefer-dynamic` when targeting Windows-like targets

error: could not compile `rustc-std-workspace-std` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `proc_macro` (lib) due to 1 previous error
Build completed unsuccessfully in 0:00:41

Luckily I know what this is caused by. But for other people, this may be confusing if they have a custom release profile.

Reproduce the failure on Windows with a global ~/.cargo/config.toml containing a release-profile LTO setting, then run x.py build. Investigate how the bootstrap build consumes that profile and verify the behavior with the reported linker error. Done means the custom profile no longer causes this bootstrap failure, with a regression check or documented result.