perf(session): flush buffered turn events in a single transaction

[rncchen]

Problem

After a turn's answer has fully streamed, _flush_buffered_events persists the
turn's buffered events one at a time via store.append_turn_event. Each call
opens a connection, looks up the turn, computes MAX(seq), inserts one row,
updates the turn, and commits — i.e. one fsync per event.

On fast SSDs this is invisible. On slower storage it dominates turn
finalisation: running DeepTutor on a Synology NAS (spinning disks, btrfs),
each commit took ~0.65 s, so a mastery-path turn with 550 buffered events
kept flushing for ~6 minutes after the visible answer had finished. Because
the terminal done event is only published after the flush, the client
spinner keeps running the whole time — the app looks hung even though the
answer is already on screen.

Evidence from the affected turn (turn_events rows, generated vs stored):

	first event	last event
timestamp (generated)	02:05:32	02:07:01
created_at (stored)	02:07:01	02:12:58

550 rows stored over ~5 min 57 s ≈ 1.5 rows/s.

Change

• Add SQLiteSessionStore.append_turn_events(turn_id, events): assigns seqs
  and inserts the whole batch inside one transaction. Measured locally:
  501 events in ~6 ms (vs minutes with per-event commits on the NAS).
• _flush_buffered_events prefers the batch method when the store provides
  one (via getattr), keeping the existing per-event loop as a fallback for
  stores without batch support (e.g. the PocketBase store, unchanged).
• When the turn has vanished mid-drain (session deleted while flushing),
  log one summary line instead of one warning per buffered event — a long
  turn previously emitted hundreds of identical
  "Skip persisting event for missing turn" warnings.

Notes

• Seq assignment semantics match the single-event path: an explicit
  seq on an event is honored; otherwise seqs continue from MAX(seq).
• No API or schema changes.