lidar-maps : navigation en cache seule et pyramide entretenue en tâche de fond

Sur une petite machine (Raspberry Pi), LIDAR_TILE_CACHE_ONLY sert les tuiles
depuis le cache uniquement (tuile absente = transparente non mémorisable,
X-Tile-Pending) et LIDAR_TILE_BACKGROUND fait surveiller les dalles par un
sondeur : chaque dalle nouvelle ou régénérée par le worker remet sa pyramide
en file, rendue à basse priorité et au ralenti. Scan et état pilotables via
/api/map/background, pré-calcul exhaustif toujours via /api/map/warm.

docs/MAPS.md

@@ -23,6 +23,7 @@ docker compose -f docker-compose.maps.yml logs -f maps
 | Variante haute densité | `/tiles/{couche}/{z}/{x}/{y}@2x.webp` — 512 px (interface interne) |
 | Zooms | 5 → 19 natif (0,2 m/px ≈ z19 en France) ; au-delà, sur-zoom côté client |
 | Hors emprise | tuile entièrement transparente (superposable), en-tête `X-Tile-Empty: 1` |
+| En attente (cache seule) | tuile transparente, en-têtes `X-Tile-Empty: 1` + `X-Tile-Pending: 1`, jamais mémorisée par le navigateur |
 | CORS | `Access-Control-Allow-Origin: *` sur `/tiles/*` |
 | Attribution | `LIDAR_ATTRIBUTION`, défaut « LiDAR HD © IGN — Licence Ouverte 2.0 » |
 
@@ -164,8 +165,7 @@ Le service est borné à chaque étage, rien n'est illimité :
 
 Les requêtes en excès attendent le sémaphore **avant** tout décodage : elles ne
 consomment ni CPU ni mémoire. Un navigateur en HTTP/1.1 n'ouvre de toute façon
-que 6 connexions par origine, toutes couches confondues ; derrière un proxy
-HTTP/2 ce plafond disparaît et seuls ces réglages tiennent la charge.
+que 6 connexions par origine, toutes couches confondues ; derrière un proxy HTTP/2 ce plafond disparaît et seuls ces réglages tiennent la charge.
 
 Le pré-chauffage (`/api/map/warm`) est séquentiel : il ne peut pas saturer la
 machine, seulement prendre du temps.
@@ -173,6 +173,47 @@ machine, seulement prendre du temps.
 Sur un Raspberry Pi 2 Go, `LIDAR_TILE_WORKERS=1` et
 `LIDAR_TILE_SOURCE_CACHE_MB=64` restent confortables.
 
+## Cache seule + maintenance de fond (petit Raspberry Pi)
+
+Sur une machine qui ne doit jamais calculer au fil de la navigation (un Pi qui
+tient aussi d'autres services), deux variables inversent la charge :
+
+```yaml
+environment:
+  - LIDAR_TILE_CACHE_ONLY=1     # la navigation ne rend plus rien
+  - LIDAR_TILE_BACKGROUND=1     # une tâche de fond entretient la pyramide
+```
+
+- **`LIDAR_TILE_CACHE_ONLY=1`** — une tuile absente ou périmée est servie
+  transparente avec `X-Tile-Pending: 1` et `Cache-Control: no-store` (le
+  navigateur la redemande : dès que la maintenance l'a rendue, elle apparaît).
+  Plus aucun rendu, ni rapatriement amont, sur le chemin des requêtes.
+- **`LIDAR_TILE_BACKGROUND=1`** — un sondeur rescane les dalles à intervalle
+  régulier (`LIDAR_TILE_BACKGROUND_INTERVAL`, 120 s) ; chaque dalle nouvelle ou
+  régénérée (le worker vient de produire, le cache à la demande vient de
+  rapatrier) met sa pyramide en file d'attente. Des rendeurs à basse priorité
+  (`os.nice`) la vident au rythme d'une tuile par
+  `LIDAR_TILE_BACKGROUND_PAUSE` seconde (1 s). Premier démarrage : TOUTES les
+  dalles sont inconnues, la pyramide se reconstruit entière — les tuiles déjà
+  fraîches ne coûtent qu'un `stat`. Les niveaux partent en file du plus petit
+  zoom au plus grand : la carte se remplit d'abord grossièrement.
+
+| Variable | Défaut | Rôle |
+|---|---|---|
+| `LIDAR_TILE_BACKGROUND_MAX_Z` | `16` | niveau maximal entretenu en fond (le natif 17–19 reste au pré-chauffage manuel) |
+| `LIDAR_TILE_BACKGROUND_SCALE` | `2` | tuiles entretenues : 2 = 512 px (celles de l'interface) |
+| `LIDAR_TILE_BACKGROUND_FMT` | `webp` | format des tuiles entretenues (celui de l'interface) |
+| `LIDAR_TILE_BACKGROUND_PAUSE` | `1.0` | pause (s) entre deux rendus — le levier de la discrétion |
+| `LIDAR_TILE_BACKGROUND_INTERVAL` | `120` | secondes entre deux scans des dalles |
+| `LIDAR_TILE_BACKGROUND_QUEUE_MAX` | `4096` | file d'attente bornée (au-delà : ignoré jusqu'au prochain scan) |
+
+Pilotage : `GET /api/map/background` (état, compteurs, file), `POST
+/api/map/background` (scan immédiat), `POST /api/map/warm` (pré-calcul manuel
+exhaustif, tous zooms/formats, cf. ci-dessous). Enfin, plafonner le conteneur
+lui-même (`mem_limit` + `memswap_limit` dans un override compose) garantit
+qu'un rendu déréglé ne peut plus emporter la machine : le tueur OOM ne
+toucherait que `lidar-maps`.
+
 ## Pré-chauffage
 
 ```bash