The previous commit released the `MemoryReservation` only at the very end of
`BlockIO::onFinish`, after `finalize_query_pipeline` (and therefore after
`CurrentThread::finalizePerformanceCounters`) had already run. The
`MemoryReservationDecreases` profile event emitted by the reservation's
destructor on the query thread then landed after the `query_log` snapshot and
was lost, so `test_scheduler_memory/test.py::test_reserve_memory` failed with
`MemoryReservationDecreases ... got 0`.

Release the memory reservation inside `finalizeQueryPipelineBeforeLogging`,
between `query_pipeline.reset()` and `finalizePerformanceCounters`. This is the
only point that satisfies every constraint at once: the pipeline (and its
threads) have already been torn down so there is no data race and the query's
real memory is already freed (no under-reporting to the memory scheduler), while
the event is still emitted before the `query_log` snapshot so it stays
attributed to the query. The reservation also stays alive through
`query_finish_callback`, which runs before `streams.onFinish`.

`BlockIO::onFinish` keeps releasing the memory reservation only on the
non-logging path; the logging path releases it inside the finalize step.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ery_log"

This reverts commit 2db56a1.

…memory

The reservation is released at query teardown (BlockIO::onFinish), after the query's ProfileEvents are snapshotted into query_log, so the decrease is not reliably attributed to the query. Asserting it per-query is race-prone; the test now checks only MemoryReservationIncreases/Killed/Failed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ease-race

Fix data race on MemoryReservation release at query finish