turbine: end the open transaction before a partition drop

[turbolytics]

Closes #437.

The bug

When a partition_owned worker's group session failed, it crashed while dropping the partitions it had lost:

error dropping revoked partitions: dropping partitions 3, 4, 5 of usage.events from usage_window:
  Invalid Argument: TransactionContext Error: Conflict on tuple deletion!
dropping revoked partitions failed; the pipeline is stopping

This was the other half of the network blip in #436: one worker stalled silently, the other crashed.

Why

The window table is written from two DuckDB connections: the pipeline's (batch inserts, the partition drop) and the window manager's (the pass that publishes closed minutes and deletes their rows). Each has its own transaction, and DuckDB's concurrency is optimistic.

The drop ran inside whatever transaction the pipeline's connection already had open. Between batches that's an idle tick's progress write, which opens a transaction and takes its snapshot before the drop takes the pass lock. If a pass then deleted the same rows and committed, the drop's DELETE hit tuples already gone, and DuckDB refused it. The pass lock couldn't help: it excludes passes from now on, not one that committed before the snapshot.

Nine statements across two connections reproduce it exactly.

The fix

dropPartitions commits the pipeline's open transaction before deleting, so the drop begins a transaction whose snapshot is after every pass the lock excludes. The progress write is rewritten at every commit, so committing it early loses nothing.

Test

TestTurbine_PartitionDropSucceedsAfterAPassDeletedTheRows drives a real Turbine with a DuckDB dropper over two connections in exactly that order, then loses the partitions.

• On main: the run stops with the crash log's error, word for word.
• With the fix: the run continues.

internal/core and internal/cli/run pass under -race.

Not reproduced end to end

Unlike #436, this one needs a window pass to land in a ~300ms gap after an idle tick, so it's timing-dependent in the stack. The two-connection test is the proof.