Add Python regression test for #866 (SIGSEGV re-executing parameterized write via implicit cache)

[adsharma]

Summary

• Adds an end-to-end regression test for Bug: QUERY_VECTOR_INDEX causes SIGSEGV on macOS ARM64 #866 by bumping tools/python_api (submodule PR: Add regression test for issue ladybug#866 (SIGSEGV re-executing parameterized write) ladybug-python#53).
• The test replicates the issue's scenario: the same parameterized write query string (CREATE (:Contribution {id: $id, embedding: $embedding})) executed repeatedly via Connection.execute() through the implicit prepared-statement cache, followed by a vector similarity read.

Root cause analysis

The reported QUERY_VECTOR_INDEX / ARRAY_COSINE_SIMILARITY SIGSEGV is not a vector-extension bug. On 0.20.0, re-executing a parameterized write query string takes the cached-physical-plan fast path (ClientContext::executeNoLock -> PhysicalPlan::prepareForReuse() -> ResultCollector::prepareForReuse() -> FactorizedTable::clear()). A write statement's root ResultCollector has an empty result schema, and the FactorizedTable constructor skips allocating flatTupleBlockCollection / inMemOverflowBuffer entirely for empty schemas, so clear() unconditionally dereferenced null (crash at 0x8).

Evidence gathered while reproducing:

• macOS crash report from the issue's exact script: EXC_BAD_ACCESS at 0x8 in lbug::processor::FactorizedTable::clear() under ClientContext::executeWithParams.
• On the 0.20.0 wheel, a script containing only the repeated parameterized CREATEs segfaults; the identical vector flow (CREATE_VECTOR_INDEX + QUERY_VECTOR_INDEX + ARRAY_COSINE_SIMILARITY) with no parameterized queries runs cleanly.
• On current main (with the empty-schema guard in FactorizedTable::clear() added in d09008e, Bug: SIGSEGV re-executing a parameterized write query string (0.20.0 regression) #862), the issue's exact script and the new test pass.

Verification

• New test SIGSEGVs against a fresh v0.20.0 build (pytest exit=139), passes on main.
• The C++ regression tests from Bug: SIGSEGV re-executing a parameterized write query string (0.20.0 regression) #862 cover the explicit prepareWithParams path; this test covers the implicit-cache path used by the Python API (Connection.execute(query, params)), which is what the issue exercised.

Relates to #866. No engine code changes needed (already fixed by d09008e for #862).