Batches that exhaust all flush retries vanish without a trace

When a batch fails every one of its retry attempts, _flush_with_retry gives up and calls record_dropped(batch) — but that function is a no-op stub, so the batch's events are gone with nothing but a log line as any trace they ever existed. This is called out in the project's own README as a known, accepted limitation; closing it means an operator or automated job can inspect what was dropped instead of losing it irrecoverably.

app/deadletter.py::record_dropped and get_dropped are no-op stubs: record_dropped does nothing, and get_dropped always returns an empty list, so a permanently-failed batch leaves no retrievable trace at all.

1. pytest practice_tickets/tests/test_ticket_19_dead_letter.py -v — flushes a batch of 2 events against an inserter that fails every attempt (flush_max_retries=1), then checks get_dropped(), which returns [] instead of the dropped batch.

_flush_with_retry's decision to drop a batch after exhausting retries is deliberate and correct (blocking a flush worker forever on one wedged batch would starve every other event behind it in the queue) — the problem isn't the drop, it's that dropping currently means "gone with no trace." A minimal, retrievable record of what was dropped turns an unrecoverable loss into a recoverable one.

Look at app/deadletter.py — record_dropped and get_dropped are already the two functions app/flush.py expects to exist (the call site is already wired in _flush_with_retry's give-up branch). Think about what module-level state record_dropped needs to hold onto so get_dropped can hand it back later.