perf(hydrology): keep flow_simulation state on the GPU across iterations

[barrulus]

Context: ottolink-dev/Hesiod#569. Depends on ottolink-dev/CLWrapper#8 (submodule bumped here; merge that first, or git submodule update will not find the pinned commit).

hmap::gpu::flow_simulation ran two cheap stencil kernels per iteration but wrapped each with blocking image uploads, a queue finish and blocking downloads: 15 full-array transfers per step. The loop now keeps depth and the four fluxes as ping-pong image pairs on the device, shares one in-order queue between the flux, water and (new) rain kernels, and reads back once at the end. The public signature is unchanged; the two existing kernels are untouched.

Grid, duration	before	after
1024², 0.2	1427 ms	64 ms
1024², 1.0	5055 ms	197 ms
2048², 1.0	36.6 s	1.95 s

Output is bit-identical to the previous implementation: golden .npy dumps from the old code for nine parameter paths (rain map, uniform rain, evaporation, closed/outflow boundaries, velocity export, odd/zero/one iterations, non-square grid) compare equal to the bit after the rewrite. The rain increment moved from a host add into a small hydraulic_vpipes_rain_pass kernel compiled with FP_CONTRACT OFF so it stays exact.

Tests: three characterization tests added (iteration parity + determinism, zero iterations, rain map of ones equals uniform rain); all FlowSimulation tests pass before and after.

Follow-ups (separate issues): the same pattern applies to flow_simulation_viscous, snow_simulation, hydraulic_vpipes and the other solvers that read back inside their loops. Also observed, pre-existing and unchanged here: with outflow_boundaries = false the clamp-to-edge sampling counts a boundary cell's own outgoing flux as inflow, so closed domains gain volume (about +40 % over 51 steps at 256² in my golden run).