Add validate-sfile, a checker for SW4 velocity models

[lispandfound]

Adds an sfile validator, which runs a number of checks over an SW4 velocity model, namely:

• All required attributes and groups exist, and the declared ngrid count matches the number of supplied grids.
• The types of the datasets match what SW4 is expecting to read. This is more important that it looks because SW4 inherits the C-style coding culture of never checking anything. So, if a double is read into a float memory buffer, it will silently write into garbage and stack smash.
• NaN and inf checks for all arrays.
• All interfaces between mesh refinements are checked to ensure they are in increasing order of depth and don't clip each other, or that the topographic gradients are not too high.
• Check that the material density is greater than zero.
• Check Vp, Vs, Qp, Qs > 0 and Vp/Vs >= 1.
• That each grid is at least two gridpoints thick.
• That the grid corners of the velocity model align with geographic coordinates.

[lispandfound]

@claude review

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[lispandfound]

@claude review

[claude]

Claude finished @lispandfound's task in 2m 35s —— View job

---

Review complete

• Gather context (diff, repo guidelines)
• Review workflow/scripts/validate_sfile.py for correctness bugs
• Check pyproject.toml change
• Post findings as inline comments
• Post summary comment

Findings: 2 (High: 2, Medium: 0, Low: 0)

1. Unhandled crash on malformed Z_interfaces datasets (_check_cross, ~line 649) — re-reads interface datasets directly instead of reusing the already-validated arrays dict, so a non-2D interface (already flagged as an error upstream) crashes the whole script with an unhandled ValueError instead of a clean failure report.
2. Dataset dtype is never actually checked (_check_dataset, ~line 514) — the PR description's headline motivation is catching dtype mismatches (double read into a float buffer → stack smash), but no code anywhere inspects ds.dtype; only value ranges/NaN/Inf are checked, so this specific failure mode currently passes validation silently.

pyproject.toml change (new validate-sfile entry point) looks correct, no issues there.

[lispandfound]

@claude review

[claude]

Claude finished @lispandfound's task in 2m 18s —— View job

---

Review complete

• Gather context (diff, prior review comments)
• Check if previously flagged issues were addressed
• Review full diff for new correctness bugs
• Post findings

The file has been substantially rewritten since the last review (798 → 1668 lines). Both previously flagged issues are resolved:

• The _check_cross/_check_z_interfaces crash on malformed Z_interfaces is gone — the new Sfile.layers/interface_arrays cached properties consistently filter out non-2D interfaces before any thickness/ordering math runs.
• Dtype checking is still not implemented, but this was already flagged in the previous review round and remains unaddressed, so not re-reported here per instructions.

New findings: 1 (High: 1)

1. Zero Vs is now flagged as an error, contradicting the tool's own zero_allowed design (_report_variable, workflow/scripts/validate_sfile.py:1215-1231) — Cs's VarSpec sets zero_allowed=True and documents zero as legal ("as it is for Vs in fluid cells"), but the zero_allowed branch yields Finding.error for n_zero instead of a warning. This is a regression from the pre-refactor code, which correctly warned rather than errored on zero Vs. As written, any legitimate model with fluid-cell layers (Vs=0) will now fail validation outright.

Posted as an inline comment with a suggested fix.