Subsecond fails to pick up new symbols on Windows

**Problem**

On *Windows* systems, a `subsecond::call(my_hot_fn)` call can fail to pick up on the new `my_hot_fn` if its return type changes.

**Steps To Reproduce**

Start with code like the following
```rust
fn main() {
dioxus_devtools::connect_subsecond();
loop {
subsecond::call(hot_tick);
std::thread::sleep(Duration::from_millis(500));
}
}
fn hot_tick() -> f64 {
println!("Initial state");
3.
}
```

Then run it with `dx serve`

This will print "Initial state" over and over again in the console.
You can now edit the `println!` to anything like `println!("Something else");`. This will change what is printed.

To reproduce the bug, edit the `hot_tick` function to
```rust
fn hot_tick() -> u64 {
println!("Please update");
3
}
```

On Windows, and probably Windows alone, this will cause the hot function to revert back to the initial one. It will now print "Initial state" again.

**Expected behavior**

It should print "Please update" in the console.

**Fixing it**

The future is bright and it contains more Rust! For some reason, switching to [the v0 mangling scheme](https://blog.rust-lang.org/2025/11/20/switching-to-v0-mangling-on-nightly/) by adding this to `.cargo/config.toml` solves the issue
```toml
[build]
rustflags = ["-Csymbol-mangling-version=v0"]
```

The nicest experience would probably be if Dioxus automatically added that rustflag on Windows and documented this behaviour? The second best option would be if Dioxus warned me about Windows screwery and told me to do that.

**Screenshots**

**Environment:**

- Dioxus version: dioxus 0.8.0-alpha.0 (3464af7) and the corresponding version of subsecond
- Rust version: rustc 1.96.0 (ac68faa20 2026-05-25)
- OS info: Windows 11
- App platform: Desktop