Thread pool design kept as a record, marked dropped

ROADMAP.md

@@ -87,6 +87,7 @@ increment that most needs a picture to check against
 | 78 | MCP over HTTP, inputs by link and by upload: a tool input may be one of the server's own download links (the caller's own, any age while the file is kept; no other address is fetched), and an `upload` tool takes a file of up to 2 MiB as text or base64 and returns its link, so a client with no shell runs a whole exchange by URI; stdio unchanged | **designed** (branch `worktree-mcp-inputs`; about 125 counted lines, worst 180) | `docs/increments/78-mcp-inputs.md` |
 | 81 | `read_mesh` returns each triangle's land-cover code: `MeshArrays` gains `land_cover_code` (int32, one per triangle, `None` when the file has none) and `land_cover_codes` (the code system's text, `""` when absent), so the reader returns what `rasputin mesh --land-cover` writes. A wrong count or type in the file is refused in plain words | **built, approved** (branch `worktree-mesh-landcover`; 31 counted lines against about 25) | `docs/increments/81-read-land-cover.md` |
 | 85 | A catchment joined from a published sub-catchment network instead of traced on the DEM (Ola's yes, 2026-10-21, ahead of the MCP feature-query tool; for forecast points on regulated Swedish rivers, where the terrain route on a surface model missed 606 km² of Kultsjön's 1,703 km², a dam embankment the likely cause): `rasputin network-catchment` (MCP tool `network_catchment`) reads a polygon file whose units each name their downstream unit (SMHI's SVAR 2022; HydroBASINS and HYPE use the same form; NVE's REGINE does not), takes a unit ID or a point or lake at a unit's published outlet, joins that unit and every unit upstream into one polygon in the file's CRS that `mesh --domain` reads, checks the area against the file's stated upstream area, and refuses cycles, missing area, a seed in no unit and a point away from its unit's outlet (never moved downstream). `--check-dem` also runs the terrain route from the same seed and reports the difference unit by unit | **built, approved** (branch `worktree-network-catchment`: red `4dddf0b0`, green `a4b530c5`, kill record `4807334e`; 479 counted lines against about 450; no C++, no `@perf`) | `docs/increments/85-network-catchment.md` |
+| 88 | The core's parallel helper keeps its threads between calls (Ola's yes, 2026-10-21): a persistent team woken per call instead of 8 new threads started on every call, so the private package's per-step kernels stop paying a start and a join each step; same block partition and output bits for every thread count, a second calling thread or a nested call falls back to today's start-and-join, the team is joined at process exit | dropped, not built (Ola, 2026-10-22): the private package's year makes 4,684 parallel calls, not the 35,000 assumed (that was threads started, 8 a call), so the pool would save about 1 to 1.5 s a year; the evaluator's time was per-receiver trigonometry, sped up in the private package's increment 89 (the sun evaluator speed-up). Design kept because that increment cites it | `docs/increments/88-thread-pool.md` |
 | — | A missing station number refused in plain words. In a reference-polygon file (`rasputin station-catchments --reference`), a feature whose `station` is null becomes the text "None" (`src_python/tin_engine/io/station_set.py@ed12512:89`). No station can match it, since a station number must look like `2.11.0` (`src_python/tin_engine/hydrography.py@ed12512:40`), so the polygon is dropped without a word and the station it belonged to is written with no comparison (`src_python/tin_engine/catchment_batch.py@ed12512:220`); two such polygons are refused as "station None appears twice". In a stations file a null number is refused, but in Pydantic's validation text rather than a sentence naming the file (`src_python/tin_engine/io/station_set.py@ed12512:79`). NVE's files have a number on every station, so only hand-made or third-party files are hit. The fix: both readers refuse a null `station`, naming the file; one or two lines. Plainer GeoJSON error messages in general are not planned until other people feed rasputin their own files | approved by Ola 2026-10-06; not designed (a small fix) | - |
 | — | A GeoTIFF whose coordinate-system GeoKeys hold garbage refused in plain words. The reader turns each code key into a whole number with `int()`, and a key stored as a double or as text can hold NaN, infinity or letters. Probed 2026-10-06 on hand-made files: NaN or text in `ProjectedCSTypeGeoKey` (3072) stops `rasputin mesh --dem` with Python's conversion message (for NaN, "Invalid value for --dem: cannot convert float NaN to integer"), which names neither the key nor the file, and infinity ends in a Python traceback (`OverflowError`) (`src_python/tin_engine/io/geotiff.py@ed12512:171`). The same holds for every other code key the reader reads: 1025, 4099, 3076, 3074, 3075, 2048 and 2054 (`src_python/tin_engine/io/geotiff.py@ed12512:310`, `src_python/tin_engine/io/geotiff.py@ed12512:176`, `src_python/tin_engine/io/geotiff.py@ed12512:339`, `src_python/tin_engine/io/geotiff.py@ed12512:352`, `src_python/tin_engine/io/geotiff.py@ed12512:362`, `src_python/tin_engine/io/geotiff.py@ed12512:499`, `src_python/tin_engine/io/geotiff.py@ed12512:423`). Worse, a fractional value is cut to a whole number first: 2.5 in 4099 is refused as 2, and 32633.5 in 3072 is read as EPSG:32633 without a word (`src_python/tin_engine/io/geotiff.py@ed12512:321`); 1.5 in 1025, 9001.7 in 4099 and 9001.5 in 3076 are likewise accepted as 1 and 9001 (probed by code review round 1 on this row's branch, exit 0). The parameter keys are already checked (`_one_number`, `src_python/tin_engine/io/geotiff.py@ed12512:454`). The fix: one check for every code key, a whole number or a refusal naming the key and its value. No real file is known to do this | approved by Ola 2026-10-06; not designed (a small fix) | - |
 | — | tifffile's warning about the NoData tag silenced. On a float32 DEM whose `GDAL_NODATA` (42113) is the lowest float32 written in 17 digits (`-3.4028234663852886e+38`), tifffile prints "parsing GDAL_NODATA tag raised ValueError: ... is not castable to float32" to stderr when the file is opened (`src_python/tin_engine/io/geotiff.py@ed12512:146`). It is noise: rasputin reads the tag itself and accepts the value, since it is that float32 exactly (`src_python/tin_engine/io/geotiff.py@ed12512:535`). The fix: silence that one tifffile message while the reader opens the file, leaving every other tifffile warning visible | approved by Ola 2026-10-06; not designed (a small PR) | - |