Persisted-event count is always 0 (or garbage) after a flush

GET /events/stats and the Prometheus /metrics endpoint are the only way an on-call engineer can tell "is ingestion actually landing rows, or just accepting requests and quietly losing them downstream?" during an incident. Both ultimately depend on AsyncpgInserter.insert_batch() correctly reporting how many rows a batch actually persisted. If that number is wrong, every capacity dashboard is wrong, every "are we dropping data" alert is either permanently silent or permanently screaming, and the load test's own headline claim ("zero data loss, verified") in the project README is unverifiable — it would be reading a broken instrument.

Postgres reports the outcome of an INSERT as a command tag string like "INSERT 0 1834" — three space-separated fields: the literal word INSERT, an OID field that's always 0 for a modern multi-row insert, and the actual number of rows affected. _rows_from_command_tag parses this tag but reads the wrong field.

1. cd fastapi/ingest_service && .venv/bin/python -c "from app.db import _rows_from_command_tag; print(_rows_from_command_tag('INSERT 0 1834'))"
2. Observe: prints 0 — should print 1834.

This is the single most common way to misparse a Postgres command tag — skimming the string as "the second token is the count" instead of checking the docs, because for SELECT/UPDATE/DELETE tags there often is no OID field and the count genuinely is the second token. The tag format isn't uniform across statement types, which is exactly what makes this an easy copy-paste mistake between codebases.

Look at INSERT_SQL and _rows_from_command_tag in app/db.py together with a real example tag ("INSERT 0 1834"). Count the fields and check which index actually holds the row count.