Index postcode lookups; don't geocode blank coordinates to 0,0

[ev-sc]

Index postcode lookups; drop a duplicate index; don't geocode blank coordinates to 0,0

• New index: adds data_record_postcode_idx on (data_source_id, lower(json->>'postcode')). This matches exactly what the REST API's EXACT filter generates, so no code change is needed. The API's postcode query drops from 1,642 ms to 0.022 ms, measured locally on a 1.75M-row data source. Estimated size on production: ~60 MB now (about 44% of rows have a postcode key), ~200 MB after the Flooded People import.
• Duplicate index dropped: removes idx_data_record_source_id_covering, a hand-made index identical to the migration-managed data_record_source_id_covering_id (btree (data_source_id) INCLUDE (id)). It had 7 scans against 3,123 for its twin since April and backs no constraint. It's the only exact duplicate in the production database. This frees ~350 MB, more than the new index adds. IF EXISTS, since no other environment has it.
• Geocoding: records with blank latitude/longitude are now left ungeocoded instead of being placed at 0,0 (Number("") is 0). Adds a unit test.
• README: adds a troubleshooting note for the Turbopack Google Fonts dev error. A stale .next/dev cache makes every route return 500; rm -rf .next/dev fixes it.

Deploying the migrations

• Postcode index: migrations run inside a transaction, so it's built without CONCURRENTLY. That blocks writes to data_record, but not reads, while it builds: 3.3 s on a 7 GB, 1.95M-row table locally, and production's table is smaller (4.1 GB heap). To avoid even that, build it by hand before deploying, and the migration becomes a no-op:

  CREATE INDEX CONCURRENTLY IF NOT EXISTS data_record_postcode_idx
  ON data_record (data_source_id, (lower(json->>'postcode')));
  

  If a concurrent build fails, Postgres leaves an invalid index behind under that name. The migration detects that, drops it and rebuilds it.

• Duplicate drop: DROP INDEX is instant, but it needs a brief exclusive lock on data_record, so it waits for queries already running on the table. The migration tool's 10 s lock_timeout limits that wait.

🤖 Generated with Claude Code

[linear-code]

MAP-1584