fix: align WALOUS with official class codes

backend/README.md

@@ -1613,9 +1613,10 @@ docker exec geointel python /app/scripts/provision_walous_sources.py \
 ```
 
 The provisioner verifies advertised archive sizes, safe ZIP structure,
-EPSG:3812, one band, 1 m cells, class values 1-11 and SHA-256 checksums. It
-does not run at application startup. `GET .../datasets/walous/products`
-therefore reports `source_not_provisioned` until both source files exist.
+EPSG:3812, one band, 1 m cells, the official non-contiguous class codes
+`1,2,3,4,5,6,7,8,9,80,90` and SHA-256 checksums. It does not run at
+application startup. `GET .../datasets/walous/products` therefore reports
+`source_not_provisioned` until both source files exist.
 
 For a bounded Walloon selection the browser persists the latest edition and
 all other configured comparable editions. `POST .../raster/walous/select`
@@ -1623,6 +1624,13 @@ returns cell-area hectares; the temporal API compares the same semantic metric
 keys for 2020 and 2023. WALOUS is land cover, not legal land use, ownership,
 tree count, timber volume or water volume.
 
+The class semantics follow the official raster codes, not display-list
+positions: 1 artificial ground, 2 above-ground construction, 3 railway, 4 bare
+soil, 5 surface water, 6 rotating herbaceous cover, 7 continuous herbaceous
+cover, 8/9 trees above 3 m and 80/90 woody cover up to 3 m. Observation ranges
+are retained from the SPW metadata rather than replaced by arbitrary year-end
+dates.
+
 Settings: `WALOUS_ENABLED`, `WALOUS_SOURCE_DIR`,
 `WALOUS_ANALYSIS_RESOLUTION_M`, `WALOUS_MAX_SIDE_M` and
 `WALOUS_MAX_PIXELS`. The SPW flood polygon adapter uses