Generate NZCVM velocity model configurations from a realisation

[lispandfound]

create-nzvm-input writes the config nzcvm generate consumes. One
realisation can produce several distinct velocity models, along two
independent axes:

--format sw4 | emod3d the grid the model is sampled onto: a
mesh-refined SW4 grid written as an sfile,
or a uniform EMOD3D binary grid
--layers full | tomography the layer stack queried to fill it: the
whole thing (basins, coastline, offshore,
Ely GTL taper) or just the background
tomography and the numerical clamps, which
is the reference no-bells-and-whistles model

Splitting those two axes is the point: comparing a full model against a
tomography-only one on the same grid is how a basin's contribution is
isolated, and it should not require hand-editing a config.

For SW4 the model is padded by more than the grid is -- one supergrid
width, as create-sw4-input uses, plus a few grid points of slack --
so SW4 never queries outside the sfile.
test_model_padding_contains_the_padded_grid asserts that ordering
directly, because if it ever inverts the symptom is a solver reading off
the end of the model rather than an error.

The nzcvm realisation section carries the layer stack as nzcvm's own
LayerConfig objects and the DEM surface as a Path, which is what the
path_serialiser added at the bottom of this stack exists to write.

The container image installs nzcvm explicitly. It is a bare requirement
resolved through [tool.uv.sources], which pip does not read, so
pip install workflow alone cannot find it. The other git-sourced
dependencies are PEP 508 direct references in dependencies and pip
resolves those itself.

Blocked on an nzcvm release: this makes nzcvm a hard import of
workflow.schemas, so every workflow install pulls it in, not just the
SW4 path.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

---

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}