Deduped events are counted as "persisted" in GET /events/stats

events_persisted_total and events_deduped_total on GET /events/stats exist specifically so someone can answer "how many events actually became new rows vs. how many were harmless retries that got deduped?" without querying Postgres directly. If deduped events get silently folded into the persisted counter, events_persisted_total runs hot (inflated by however many retries happened) while events_deduped_total stays permanently at zero — making it look like the idempotency mechanism isn't doing anything, right when someone is trying to verify it is.

Stats.record_deduped(n) is supposed to add n to the deduped-events counter used by GET /events/stats. Instead it adds n to the persisted-events counter — the separate Prometheus counter update in the same method is correct; only the in-process counter is wrong.

1. cd fastapi/ingest_service && .venv/bin/python -c "from app.metrics import Stats; s = Stats(); s.record_persisted(1); s.record_deduped(2); print(s.events_persisted_total, s.events_deduped_total)"
2. Observe: prints 3 0 — should print 1 2.

This is a copy-paste mistake between two nearly-identical methods (record_persisted and record_deduped differ only in which counter and which Prometheus object they touch) — exactly the kind of bug that survives code review because the two methods look almost the same at a glance and the Prometheus half of the bugged method is actually correct.

Compare record_persisted and record_deduped line by line in app/metrics.py. One of them is incrementing the wrong attribute on self.