dx asset bundling silently fails under wasm-threads rustflags (follow-up to #5079, still reproduces on dx 0.7.9)

## Summary

On dx 0.7.9, `dx build --platform web` fails to bundle and patch `asset!()` records when the wasm-threads rustflags (the same set used by [`wasm-bindgen-rayon`](https://github.com/RReverser/wasm-bindgen-rayon) and `cpal`'s `audioworklet` backend) are present. PR #5163 and PR #5189 were the previous round of fixes for this class of bug (#5079, #5188) and they're both in 0.7.9, but the warnings from #5188 still appear and the `public/assets/` directory ends up empty.

## Reproducer

Minimal isolated repro: https://github.com/uditrugman/dx-wasm-threads-asset-repro

- One dioxus web app, `main.rs` has one `asset!()` call.
- One asset: `assets/style.css` (~30 bytes).
- `.cargo/config.toml` with the wasm-threads rustflags from #5079.
- **No cpal, no rayon, no threads spawned, no other crates.** Just `dioxus = "0.7.9"`.

### With the rustflags

```
$ dx build --platform web
…
WARN Failed to deserialize as BundledAsset. Data length: 4096,
first 32 bytes: [119, 97, 115, 109, 45, 116, 104, 114, 101, 97,
100, 115, 45, 97, 115, 115, 101, 116, 45, 114, 101, 112, 114,
111, 47, 97, 115, 115, 101, 116, 115, 47]
WARN Found a symbol at offset 4213283 that could not be deserialized.
This may be caused by a mismatch between your dioxus and
dioxus-cli versions, or the symbol may be in an unsupported format.
WARN Found a symbol at offset 4217379 that could not be deserialized.
…
INFO Running wasm-bindgen...
INFO Client build completed successfully!
```

- The byte pattern decodes to `"wasm-threads-asset-repro/assets/"` — that's literally the asset path. dx finds the right offset but can't deserialize the record.
- `target/dx/.../public/assets/` is empty.
- 3 unpatched `"This should be replaced by dx..."` placeholder strings remain in the wasm.

### Same source without the rustflags

```
$ mv .cargo/config.toml .cargo/config.toml.bak && rm -rf target/dx
$ dx build --platform web
…
INFO Copying asset (1/1): /…/assets/style.css
INFO Client build completed successfully!

$ ls target/dx/.../public/assets/
style-dxh869c7541c5a361e.css
```

Works exactly as expected.

## Versions

- `dx --version` → `dioxus 0.7.9 (bfcc111)`
- `dioxus = "0.7.9"` (matches dx)
- All `manganis*`, `dioxus-cli-config`, `dioxus-core`, `dioxus-web` = 0.7.9
- nightly Rust, `rust-src` component installed.

`manganis-core` 0.7.9 intentionally pulls both `const-serialize 0.7.2` and `0.8.0-alpha.0` (with the 0.8 having a `const-serialize-07` feature for read-side backcompat). The "mismatch between your dioxus and dioxus-cli versions" warning's first half doesn't apply.

## What's *not* the cause (ruled out in the repro)

- **Extra rustflags vs the original #5079 setup** (`+mutable-globals`, `--export=__heap_base`). Removing both → identical warnings.
- **Debug symbols.** `--debug-symbols=false` → identical warnings.
- **Inject loading scripts.** `--inject-loading-scripts=false` → still empty `public/assets/`.
- **A `cpal` or `rayon`-specific issue.** The repro has *neither*.

## Hypothesis

The rustflags (probably `--shared-memory` + `--import-memory` + the TLS exports together with `-Z build-std=std,panic_abort` so std is rebuilt with `+atomics`/`+bulk-memory`) change the wasm data-section layout in a way `find_wasm_symbol_offsets` doesn't account for. dx does locate the candidate offset (the byte preview proves the asset record *is* found), but the structured deserialization fails — beyond what PR #5163 added.

Happy to do more digging into the wasm-side encoding if it'd help.