fix(cpp): switch BLOB buffers to array shared_ptr

[pbbadenhorst]

Summary

BLOB pointers returned from sqlite3_column_blob() are SQLite-owned (the result memory is freed by SQLite when execution advances), so op-sqlite copies each BLOB into its own buffer with new uint8_t[N] before handing it off to JSI. The owning smart pointer was std::shared_ptr<uint8_t> — whose default deleter calls scalar delete, not delete[]. Mixing new T[] with scalar delete is undefined behaviour and can surface as heap-metadata corruption: on libc++ (iOS) and scudo (Android) the array cookie placed in front of the allocation by new T[] is bypassed, the allocator frees the wrong block, and follow-on allocations may crash later in unrelated code.

The fix switches the smart-pointer type to the C++17 array specialization std::shared_ptr<uint8_t[]>, which captures std::default_delete<uint8_t[]> and thus calls delete[] on destruction. The change is a single-character template-parameter edit at the type declaration plus every construction site.

Changes

• cpp/types.hpp: ArrayBuffer::data field type changed from std::shared_ptr<uint8_t> to std::shared_ptr<uint8_t[]>.
• cpp/utils.cpp, cpp/bridge.cpp, cpp/libsql/bridge.cpp, cpp/turso_bridge.cpp: every ArrayBuffer{.data = std::shared_ptr<uint8_t>{data}, ...} construction site updated to std::shared_ptr<uint8_t[]>{data} (11 sites in total across SQLite, libsql and Turso execute paths — including the executeRaw, prepared-statement, and host-object variants).

No consumer changes were needed: every reader calls .data.get(), which returns T* identically for the scalar and array specializations.

[ospfranco]

awesome, thanks for the fix!