Fix insert() leaving an undestroyable container when a constructor throws

[martinus]

Fixes #68.

make_uninitialized_space() shifts the elements at pos out of the way and immediately counts the resulting gap in size(). Until the caller constructs into that gap the container claims raw memory, so a throwing element constructor left it in a state that could not even be destroyed:

size=2 capacity=8
inserting 3 copies, the 2nd throws...
caught: copy
after: size=5
ERROR: AddressSanitizer: heap-use-after-free
  #6 ThrowOnCopy::~ThrowOnCopy()
  #7 std::_Destroy<ThrowOnCopy>(ThrowOnCopy*)

size() says 5 while slots 0 and 1 hold objects std::uninitialized_fill_n had already destroyed on its way out.

Fix

All five callers (emplace, both single inserts, the count insert, the forward-iterator range insert) now go through fill_uninitialized_space(), which closes the gap again if the fill throws.

close_gap() has two modes:

• relocating T cannot throw — shift the tail back down; the container ends up exactly as it started.
• otherwise — drop the tail. Shorter, but valid and destroys cleanly.

std::move_if_noexcept, the usual way to preserve elements of a throwing-move type, is deliberately not used: close_gap runs mid-unwind, and a throwing copy there would be a second exception in flight and std::terminate.

That split matches the standard. [sequence.reqmts] only requires the strong guarantee for a middle insert when moving cannot throw, and the basic guarantee otherwise.

Tests

test/unit/insert_exception_safety.cpp sweeps sizes 0-9 × every position × counts 1-5 × first/last throw point, across insert(pos, count, v), insert(pos, first, last), insert(pos, v) and emplace, in both storage modes and across the reallocating boundary. For the nothrow-move type it asserts the contents are byte-identical to before; for the throwing-move type asan and the leak checker do the asserting.

Reverting the guard reproduces the heap-use-after-free immediately.

Measured cost

Reviewed the codegen rather than assuming. For svector<int, 8> the try/catch is fully elided — identical .text size (5851 bytes), no landing pads, no .gcc_except_table entries. For svector<std::string, 8> the TU grows 3.9%, almost all of it one out-of-line close_gap per T — it is not templated on the lambda, so the five call sites share it. fill_uninitialized_space inlines away entirely at -O3.

Not fixed here

make_uninitialized_space_new() has the same shape of bug on the growth path: if a move throws partway through relocating into the new storage, the elements already moved are leaked. Confirmed with asan and filed as #74, along with the deeper redesign that would remove this whole family of problems.