Fix double free when retain unwinds

[tooson9010-spec]

retain compacts kept elements with ptr::copy_nonoverlapping and commits the
new length only after the loop. Two ways a panic leaves the buffer unsound:

• The predicate unwinds after a compaction. copy_nonoverlapping leaves the
  source slot as a byte-for-byte duplicate, so both copies stay inside 0..len
  and StackVec::drop frees the same value twice. No element Drop has to
  panic — an unwrap() or assert! in the predicate is enough.
• A removed element's Drop unwinds. The slot was already destroyed but stays
  inside 0..len.

Reported in #3.

Reproducer

The added tests count destructor calls on a 4-element vec. Both paths destroy
more than exist:

5 drops for 4 elements

AddressSanitizer reports attempting double-free with a heap-owning element
type.

The fix

Retire the buffer up front and let a backshift guard restore a correct length on
every exit path, the same shape Vec::retain uses. The removed slot is counted
out before drop_in_place, so a panicking element Drop can't be revisited
either.

Regression test

Two cases in src/stack_vec.rs, one per path. cargo test catches both, no
sanitizer needed; retain_with_drops and the retain doc-test still pass.

[OverwrittenCode]

Verified the fix locally: cargo miri test --all-features and
cargo clippy --all-features -- -D warnings both pass, including
the two new panic-safety regression tests.

Pushed two small fixups on top:

• resolved a Stacked Borrows violation Miri caught in the
  BackshiftOnDrop guard and the retain loop (interleaved
  as_ptr()/as_mut_ptr() calls were invalidating each other's
  reborrows)
• moved the item definitions before the first statement and
  split a 3-op unsafe block to satisfy clippy::pedantic

Thanks for the clear repro and the regression tests - good catch.