Feature: Memory Safety

### Describe what you are looking for

We should explore recent memory safety extensions and their applications to StringZilla interfaces and string classes. Namely, consider `__ARM_FEATURE_MEMORY_TAGGING`, AddressSanitizer & MemorySanitizer poisoning, and C++26 contracts. At this point we only do this:

```cpp
/**
* @brief For higher safety, we annotate the lifetime bound of the returned string slices.
* https://clang.llvm.org/docs/AttributeReference.html#id11
* https://lemire.me/blog/2024/07/26/safer-code-in-c-with-lifetime-bounds/
*/
#if !defined(__has_cpp_attribute)
#define sz_lifetime_bound
#elif __has_cpp_attribute(msvc::lifetimebound)
#define sz_lifetime_bound [[msvc::lifetimebound]]
#elif __has_cpp_attribute(clang::lifetimebound)
#define sz_lifetime_bound [[clang::lifetimebound]]
#elif __has_cpp_attribute(lifetimebound)
#define sz_lifetime_bound [[lifetimebound]]
#else
#define sz_lifetime_bound
#endif
```

### Can you contribute to the implementation?

- [x] I can contribute

### Is your feature request specific to a certain interface?

C++ bindings

### Contact Details

_No response_

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start with the C++ bindings and the existing sz_lifetime_bound annotation shown in the issue. Review the listed memory-safety extensions—ARM memory tagging, sanitizer poisoning, and C++26 contracts—and determine which interfaces and string classes they apply to. Done means a scoped implementation plan identifies applicable extensions and affected C++ interfaces.

Written by the indexing model from the issue text.