FP: double free and use-after-free on format! and vec! inside a loop

[HardMax71]

627ddfd, the fix for #289, cleared the to_owned and nested-loop cases, but format! and vec! inside a loop still report:

pub fn run(n: usize) -> usize {
    let mut total = 0;
    for i in 0..n {
        let s = format!("{i}");
        total += s.len();
    }
    total
}

warning: Double free detected.
warning: Double free detected during unwinding.
warning: Use-after-free detected.
Double free (confidence 99%): Location in file src/lib.rs line 1.
Use-after-free (confidence 99%): Location in file src/lib.rs line 5.
MIR detail: Value _16(s, src/lib.rs:4) and _16(s, src/lib.rs:4) are alias.
MIR detail: _16(s, src/lib.rs:4) is dropped at BB12(src/lib.rs:6); _16(s, src/lib.rs:4) is used at BB10(src/lib.rs:5).

vec![i] in place of format!("{i}") gives the same three reports on v.

The drop record is cleared now, but the value stays in a stale alias class. As far as I traced it on an earlier main, the first iteration's callee summary (must_use for format!, box_assume_init_into_vec_unsafe for vec!) merges the destination and its argument into one class. On the next iteration the argument gets a new value, from a call or through a plain move, which in safedrop mode doesn't touch the points-to graph. So it never leaves the class, and fetch_drop_from_alias picks up the previous iteration's drop.

Resetting the partition for may-drop call destinations and untracked move destinations cleared both, with no test regressions then. But it splits the whole class and changes MoP alias results, so it's a precision call I'd rather leave to you.

On our workspace this shape is 51 of the 491 check -f reports left after the merged fixes.

RAPx at 51e2070 (main), nightly-2026-09-22 (rustc 1.100.0-nightly 1303417c4 2026-09-21), cargo rapx check -f.