feat(maps)!: map tiles are stored once for every account, in place of per-record pictures

[aleskiontherun]

GET /map-tiles/{theme}/{z}/{x}/{y} serves one square of the Web Mercator grid, drawn by the map renderer the first time any signed-in account asks for it and stored once for the whole instance in a new map_tile table with no account column, so every record and account whose map covers a tile shares one draw; a zoom past 9 or a square outside the grid is a 404 before anything reaches the renderer. The three per-record …/map-picture routes, map_picture on DiveListItem, TripRead and DiveSiteRead, and the map_picture table go, and GET /config says map_tiles in place of map_pictures — a breaking contract change whose web half (the renderer's tile mode and maps composed from tiles) ships in opendiving-web and merges back to back with this; until both are deployed, cards show water. MAP_PICTURE_RATE_LIMIT_* become MAP_RENDERER_DRAW_LIMIT_PER_USER (draws an account starts) and MAP_RENDERER_REQUEST_LIMIT_PER_USER (every tile request, stored ones included, which slows a timing probe of the shared store) over MAP_RENDERER_LIMIT_WINDOW_SECONDS. Tiles are nobody's data: no storage limit, no export, untouched by an account's purge; the sweeper knows the map-tiles kind and the hourly cron deletes one unserved for 30 days. Revision bb0a5f425d41 drops map_picture and copies nothing, so the dropped rows' files under map-pictures/ are orphans for sweep_orphaned_files --delete, with --force where they exceed a quarter of the store (a few megabytes on the hosted instance). No Redis flush is needed: no cached response ever held a digest, the field having been filled after the cached read, and every @cache key carries the build.

Verified with the full suite against Postgres with no skips, coverage, ruff, mdformat, the three mypy runs, and alembic upgrade head, downgrade -1, upgrade head and alembic check on a scratch database.

🤖 Generated with Claude Code