[kitkatt7]

Description

When a bound function takes std::string_view and is passed a bytearray, string_caster::load_raw gives the view a pointer straight into the bytearray's storage and only registers the bytearray object itself with loader_life_support. That keeps the object alive but not its buffer: a bytearray is resizable, so any Python code that runs while the C++ function is still using the view (a callback it invokes, or another thread when the function uses py::call_guard<py::gil_scoped_release>() or runs on a free-threaded build) can reallocate it. In the new test, string_view_call_then_copy(buf, lambda: buf.extend(b"y" * 1_000_000)) reads the view after the callback returns, and an ASan build with PYTHONMALLOC=malloc reports a heap-use-after-free in the bound function with the free in PyByteArray_Resize; without ASan the returned bytes start with a stale allocator pointer. bytes and str are immutable, so only the bytearray path is affected. On CPython the caster now keeps a memoryview of the bytearray alive for the call instead, which is the same export mechanism memoryview/numpy rely on, so a resize during the call raises BufferError and the bytearray is resizable again as soon as the call returns. PyPy and GraalPy keep the old behaviour: there the export is only released when the GC collects it, which would leave the bytearray locked well after the call, and I could not reproduce the corruption on PyPy 3.11. Tested with the full suite on CPython 3.12 (Debug, PYBIND11_WERROR=ON), test_builtin_casters on 3.13t, PyPy 3.11 and C++11, and the new test fails without the cast.h change.

Suggested changelog entry:

• Fixed a use-after-free when a bytearray passed as a std::string_view argument was resized while the bound function was running; on CPython the bytearray now cannot be resized for the duration of the call.