occurred_at defaults to a naive (timezone-less) local timestamp

Every event whose client doesn't supply occurred_at explicitly gets timestamped with datetime.now() — a naive datetime with no timezone attached, representing whatever the server process's local clock says. Events that do supply occurred_at get a timezone-aware datetime. These two kinds of timestamps end up mixed together in the same occurred_at::timestamptz[] array sent to Postgres on every batch flush; Postgres silently interprets a naive timestamp using the server's session timezone, not necessarily UTC and not necessarily the same timezone the process's wall clock is actually running in. The result is a systematic, silent timestamp skew for exactly the events a client trusted the server to timestamp correctly — and it's the kind of bug that can pass every test running in a UTC CI environment and only show up once a deployment lands somewhere that isn't UTC.

Every event whose client doesn't supply occurred_at gets timestamped with a naive (timezone-less) local datetime, while events that do supply occurred_at get a timezone-aware one from Pydantic's ISO-8601 parsing. The two kinds end up mixed in the same array cast to timestamptz[] on every batch flush, and Postgres silently interprets a naive value using its own session timezone rather than raising an error.

1. cd fastapi/ingest_service && .venv/bin/python -c "from app.schemas import EventIn, EventRecord; e = EventIn(device_id='d1', event_type='t', sequence=1); r = EventRecord.from_event_in(e); print(r.occurred_at, r.occurred_at.tzinfo)"
2. Observe: prints a datetime with tzinfo=None — should have tzinfo=UTC (or another fixed offset), matching what a client-supplied occurred_at gets.

datetime.now() and datetime.now(timezone.utc) differ by exactly one argument and both "look correct" if you're not specifically checking for timezone-awareness — the bug is invisible in any environment where the machine's local time already happens to be UTC, which is exactly what makes it a production-only surprise. This is a genuine cross-component contract mismatch: Python's naive-vs-aware datetime distinction meets Postgres's "silently assume session timezone" behavior for naive input to a timestamptz column — neither side raises an error, they just disagree quietly.

Look at EventRecord.from_event_in in app/schemas.py. Compare the occurred_at = event.occurred_at or datetime.now() line against how the rest of this codebase already reaches for UTC elsewhere.