MVT tile caching

[sebprunier]

Goal

Tile responses currently set Cache-Control: max-age=3600 but every request re-runs the ST_AsMVT query. On large collections (millions of features) this is the dominant cost. A persistent server-side cache would dramatically reduce CPU and DB load.

Scope

• Cache key: {collection_id}/{z}/{x}/{y}.pbf
• First implementation: filesystem under a configurable CACHE_DIR (env var or sanson_config entry)
• Interface designed so a Redis or S3 backend can replace the filesystem later without touching the route code
• TTL configurable (reuse tiles.cache_ttl_seconds from sanson_config)

Invalidation

• Re-import of a collection drops the data table — must also drop the cached tiles for that collection
• Collection deletion drops the cache for that collection
• Style update does NOT invalidate (style is applied client-side via the /collections/{id}/style endpoint)

Acceptance criteria

• TileCache interface with a filesystem implementation
• Cold miss path stores the tile bytes; warm hit serves from cache
• Re-import hook (worker) clears the collection's cache
• Collection delete handler clears the cache
• Hit/miss counters exposed in /api/admin/health
• Vitest integration tests: cold miss → store, warm hit → serve, invalidation on re-import and on delete
• Documentation: docs/api/vector-tiles.md + CLAUDE.md "Key architectural decisions"

Out of scope

• Distributed cache backends (Redis, S3) — keep the interface ready
• Pre-warming / cache priming
• Per-collection TTL overrides