fix: guard temporary strings and string arrays during conversions

[milyin]

Several getters and conversions release temporary C strings or string arrays only after building a C++ result. An allocation failure skips that release; Id stream insertion has the same problem if the stream throws.

Add internal scope guards and use them at all twelve existing temporary string/string-array conversion sites:

• detail::String, based on Owned<z_owned_string_t>, protects Id::to_string, Id stream insertion, Config::get/to_string, Encoding::as_string, four Link string getters, and string deserialization.
• detail::StringArray protects Link::get_interfaces and the zenoh-c path of Hello::get_locators. Its as_vector() makes independent string copies. Array initialization uses z_string_array_new, which creates an allocation-free empty state on both backends and avoids zenoh-pico's missing C++ string-array z_internal_null overload.

Public signatures and ownership contracts are unchanged. Hello's returned views still borrow its strings. Empty/null temporary strings convert to empty C++ strings, and length-based conversions preserve embedded null bytes.

Tests cover normal and empty conversions, embedded nulls, copies outliving C storage, injected C++ allocation failures, and throwing stream output. A custom C string deleter verifies cleanup during unwinding directly. Fault injection is confined to separate test executables; it does not affect C-side allocation.

Validation on macOS arm64:

• String guard, string-array guard, and existing serialization tests passed with upstream zenoh-c 1.10.1 and the available zenoh-pico build.
• Strict-warning builds and compilation with exceptions disabled passed for both backends.
• macOS leaks --atExit reported zero leaks for both guards' regression executables on both backends, including the allocation-failure and stream-exception paths.