Add irrigation proof-of-concept

[HendrikKok]

Fixes #3118

Irrigation module; proof-of-concept

Adds a standalone irrigation/ module wrapping Wflow's SBM land-surface
components (soil, interception, runoff, non-paddy demand) to prototype a
coupled irrigation loop with Ribasim.

Coupling concept

Each timestep should have the following update pattern:

sequenceDiagram
    participant R as Ribasim
    participant W as Irrigation module
    Note over W: get_demand() — soil moisture @ t-1
    W->>R: demand [m/s]
    Note over R: update_until(t)
    R->>W: allocated [m/s]
    Note over W: set_allocated()
    Note over W: update_until(t)

Loading

API

m = Irrigation.init(; n = 4)           # n independent soil columns

for step in 1:nsteps
    demand = Irrigation.get_demand!(m)              # [m/s] — reads t-1 state
    allocation = ribasim_route(demand)              # placeholder: Ribasim BMI
    Irrigation.set_allocated!(m, allocation)
    Irrigation.update_until!(m, step * m.dt)        # advance Wflow to t
end

Notes

• Wflow pinned to ea8754e (1.1.0-dev) via [sources] in irrigation/Project.toml; remove when 1.1.0 is released to the registry
• run_irrigation.jl runs three standalone scenarios (no allocation / 50% / multi-column) and saves water budget plots

IO design thoughts

• Soil/vegetation parameters read from a NetCDF at initialisation (produced by HydroMT)
• Ribasim init receives the NC file path + an irrigation_id → water_user_id mapping, so it knows which allocation to route back to which soil column

Open questions:

• Does Ribasim hold the mapping, or does the irrigation module?
• Is the mapping defined in the NC file, in the Ribasim model, or as a separate config?
• Could we reuse Wflow's existing NC parsing to read HydroMT output directly, rather than writing our own reader? Concern: Wflow's reader is built around 2D spatial grids

[github-advanced-security]

Trivy found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.