Fix erase() of an empty range blanking the tail

[martinus]

Fixes #66. Same class of bug as #65, different function.

v.erase(it, it) blanked every element from it onwards:

erase(it, it)
  svector       [<EMPTY!> <EMPTY!> <EMPTY!> ]
  std::vector   [aaaa... bbbb... cccc... ]

erase_checked_end ran std::move(erase_end, container_end, erase_begin) unconditionally. With first == last the destination equals the source begin, which std::move does not allow, and every element self-move-assigns.

This was the last one

Grepped the whole header for the assigning algorithms. There are exactly two raw call sites:

line	call	status
492	std::move(...) in erase_checked_end	fixed here
581	std::move_backward(...) in shift_right	fixed in #65

Every other data movement goes through std::uninitialized_move / std::uninitialized_copy / std::uninitialized_fill_n, which construct into raw memory and so cannot self-assign. The remaining std::move hits are the single-object cast, not the algorithm. So this bug class is now fully covered.

Depth

The guard belongs in erase_checked_end, not the public erase(): to is clamped against container_end first, so a range can be non-empty on entry and still clamp to empty. Checking first == last in the caller would miss that case, and re-deriving the clamp there would duplicate the logic.

It reuses num_erased (hoisted above the guard) instead of spelling "nothing to erase" a second way as a pointer comparison.

Tests

One case in test/unit/erase.cpp, covering begin/middle/end positions in both storage modes. Fails without the guard.

make_long_strings() moved into test/app/VecTester.h — #65's test grew the same "strings long enough to defeat SSO" scaffolding in insert.cpp, and this would have been the second copy. Both now call the helper.

Verified with gcc and clang under -fsanitize=address,undefined.