chore(deps): rusty_alloc 2.2.0 -> 2.2.5; minor-bump the crates that pin it

[Ttimmahlax]

Upgrades rusty_alloc and rusty_alloc-api from =2.2.0 to =2.2.5 in every crate that pins them.

Versions

The pin is exact, so a consumer that pins rusty_alloc itself has to move with it. Each crate therefore takes a minor bump:

crate	from	to
ffai-argus	0.7.5	0.8.0
ffai-argus-wasm	0.1.3	0.2.0
ffai-carmenta	0.11.0	0.12.0
ffai-carmenta-wasm	0.2.3	0.3.0
ffai-cli	0.7.0	0.8.0
ffai-diana	0.7.8	0.8.0
ffai-mercury-wasm	0.1.3	0.2.0
ffai-wasm	0.1.5	0.2.0

Why 2.2.5

• 2.2.5: builds on MSVC with LTO and panic = "unwind". That is our release profile, and 2.2.1 to 2.2.4 failed to build on it.
• 2.2.4: freed model memory is no longer stranded after a loader thread exits, and freed huge blocks are purged.
• 2.2.3: a failed Windows re-commit becomes an allocation failure instead of an access violation.
• 2.2.1: realloc of a huge block copies only the requested size, start-up makes 12 allocations instead of 263, and a cross-thread double free aborts instead of hanging.

The semver hazard in 2.2.4 is new public fields on Heap. FFai never builds one with a struct literal.

Checks run locally

All pass:

• workspace cargo check --all-targets;
• the three blocking clippy gates;
• cargo check on wasm32-unknown-unknown for the four wasm crates;
• lib tests for the allocator crates (186 tests);
• cargo vet and cargo deny;
• a release build of ffai-cli on x86_64-pc-windows-msvc with our thin-LTO, unwinding profile: it links and runs.

Merging this publishes through release-plz.

🤖 Generated with Claude Code