fix rust-analyzer false positives with VScode

[karencfv]

rust-analyzer on VScode seems to have issues. I realise the current code is correct but I'm tired of the red squiggly line popping up here if I enable the rust analyzer extension.

According to claude:

You're right that the code is correct. This is a rust-analyzer false positive — its simplified borrow checker sees an immutable borrow of batch on line 2702 (p.found_batch(&batch, ...)) immediately followed by a mutable borrow on line 2703 (rows.append(&mut batch)). Even though these borrows are sequential and rustc has no issue with them, rust-analyzer can flag this as a potential conflict.

Your options to silence the IDE without changing behavior:

• Restructure to remove the overlapping borrows — swap append for extend, which consumes batch (moves it) instead of mutably borrowing it, so rust-analyzer no longer sees competing borrows. This is the cleanest fix and consistent with the pattern used elsewhere in the same function (e.g., line 2669 uses extend). The two calls are semantically equivalent for Vec.

• Add a #[allow] annotation — if the complaint is a specific lint (e.g., unused_mut), you can suppress it with #[allow(unused_mut)] on the let mut batch binding. But this only works if the complaint is a warning/lint, not a false-positive "error" from rust-analyzer's borrow checker.

• Live with it — if neither option is appealing, rust-analyzer false positives on sequential borrows like this are a known limitation and harmless since cargo build / cargo check passes cleanly.

The root cause is that rust-analyzer's analysis is conservative: it sees two borrows of batch in close proximity and doesn't always correctly determine that the first borrow has fully ended before the second begins.

This is purely a quality of life improvement for an issue that may just be impacting me, so I'm OK if this PR is rejected

[sunshowers]

Seems great, thanks for doing that!