Optimize prepared scalar execution

[skuirrels]

Summary

• add a direct ExecuteScalar fast path for reusable prepared statements
• read and dispose only the first result vector instead of constructing a full DuckDBDataReader
• retain the former reader path as a same-process benchmark comparison
• cover values, SQL nulls, empty results, non-query statements, representative reader types, streaming mode, and reuse after materialization failure

Performance

The paired same-process benchmark measured the prepared scalar path at 22.95 us and 176 B versus 23.62 us and 944 B through the former reader path. That is approximately 2.8% lower mean time and 81.4% lower managed allocation, with Gen0 collections eliminated for the measured operation.

The exact-branch rerun was noisy under the active VM, so the reliable claim is the allocation reduction rather than a statistically significant latency improvement.

Validation

• focused DuckDBCommandTests: 20 passed
• full test suite: 7,012 passed, 0 failed
• Release solution build: succeeded for net8.0 and net10.0
• fork preview bindings and data packages: packed successfully
• packaged preview smoke test: passed against DuckDB v1.5.4
• git diff --check: clean