fix(stl_bind): correct __delitem__ for negative-step slices and re-enable contiguous erase fast path

[henryiii]

🤖 AI text below 🤖

Bug

bind_vector's __delitem__(slice) in stl_bind.h advanced the erase
index by step - 1 for every slice, but that correction is only valid
for positive steps (where erasing an element shifts the later
elements down by one). For negative steps the visited indices are
strictly decreasing, so erasing never shifts them and the - 1 is
wrong:

• del v[::-2] on [0, 1, 2, 3] produced [1, 2] instead of the
  correct [0, 2] (silent data corruption).
• del v[::-1] ended up calling v.erase(v.begin() - 1), an
  out-of-bounds access (observed SIGBUS).

Separately, the contiguous fast path was guarded by step == 1 && false
— a debugging artifact from 2016 (25c03ce) — so a contiguous delete
like del v[1:1000] did 999 individual erase calls instead of one
range erase.

Fix

• Use the signed slice::compute overload so negative steps stay signed
  instead of arriving as wrapped size_t values.
• Advance by step for negative steps and step - 1 for positive
  steps.
• Drop the dead && false, restoring the O(n) contiguous range erase for
  step == 1.

Semantics now match CPython del l[slice] exactly for forward,
strided, negative, empty, and full slices.

Tests

Added test_vector_delitem_slice in tests/test_stl_binders.py,
looping over forward / strided / negative-step / empty / full slices for
vectors of several lengths and comparing against the equivalent Python
list del.

Verification

Built a scratch opaque VectorInt module against this branch's headers
and compared del v[...] to Python list semantics across all the slice
cases above (and more) for lengths 0–11 — all match, no out-of-bounds
access.

Part of #6084