device_id and event_type are silently swapped on insert

Every event this service has ever ingested since this bug was introduced has its device_id and event_type columns swapped in the database. Nothing crashes: both columns are TEXT, both arrays are the same length, Postgres has no way to know the meaning of the values it's being handed doesn't match the column names they're going into. Any downstream consumer of this table — analytics grouping by device_id, an alert rule filtering on event_type = 'error', a support tool looking up "what has device X sent" — silently gets nonsense results that look superficially plausible, which makes this the kind of bug that can go undetected for a very long time and corrupt a correspondingly large amount of historical data before anyone notices something is off. This ticket requires a real Postgres to run at all — the bug is invisible to any test that only checks "did a row get inserted," it only shows up when you check which column a value landed in.

AsyncpgInserter.insert_batch builds three parallel lists (event_keys, device_ids, event_types) and passes them to conn.execute for an INSERT whose column list is (event_key, device_id, event_type, payload, occurred_at) — but the 2nd and 3rd positional arguments passed to conn.execute are in the wrong order relative to that column list.

1. export TEST_DATABASE_URL="postgresql://<you>@localhost/ingest_test" (see project README for setup)
2. Insert an EventRecord with device_id='dev-42', event_type='click' via AsyncpgInserter.insert_batch, then query the row back.
3. Observe: {'device_id': 'click', 'event_type': 'dev-42'} — swapped.

Passing several same-typed positional arguments to a parameterized query is a well-known footgun precisely because the type system can't catch a reordering — TEXT[] and TEXT[] are indistinguishable to asyncpg no matter which Python list ends up in which slot. The only thing that catches this class of bug is checking the query's column list against the call site's argument order, by hand, every time — or writing a test that checks which value ends up in which column rather than just "did a row appear."

Line up INSERT_SQL's column list (app/db.py) against the argument order in the conn.execute(...) call in AsyncpgInserter.insert_batch, position by position.