Disable cached physical-plan reuse for parameterized write statements

[ericyuanhui]

fix #875

Root Cause
The Python API implicitly caches parameterized prepared statements. When parameter types remain unchanged, repeated write executions previously reused the cached physical plan and execution-state allocations.

For MERGE ... SET r.property = ..., the MERGE operator projects the relationship internal ID into a result vector, and the following SET_PROPERTY operator consumes that ID.

A relationship created by MERGE receives a transaction-local ID. On a later auto-commit execution, a stale relationship ID from the previous execution can remain visible to SET_PROPERTY. The new transaction has no corresponding LocalRelTable, so RelTable::update() obtains a null local table and dereferences it, causing a segmentation fault.

This does not affect a plain relationship MERGE without a subsequent property update because no SET_PROPERTY operator consumes the projected relationship ID.

Fix
Disable cached physical-plan reuse for parameterized write statements.

Parameterized writes still reuse the cached parsed statement and logical plan, but each execution now rebuilds its physical plan and execution state. This prevents transaction-local IDs from surviving across auto-commit transactions.

Cached physical-plan reuse remains enabled for read-only parameterized statements.

[adsharma]

c660661

in #878 does something similar.