Accept negative foundationDepth — it is a NAP level, not a length

[yorickdewid]

Problem

A Data Studio user could not save "Onderkant fundering" and got the generic
Opslaan van dit adres is niet gelukt. toast, which reads like a database fault.
It isn't — it's a validator/frontend contract mismatch.

foundationDepth was validated with numericLength (gte(0)), while ClientApp
renders the field with the LEVEL preset (unit m NAP, min -999.99). Every
below-datum value — i.e. essentially every real one — came back a 400.

Reported against inquiry 156423 (no_pile sample, Hoofdweg 80A Lijnden),
which is precisely the non-piled case the field's own hint says it's for. The
record has been stuck since 5 August.

Of the 18 numeric sample fields, this was the only mismatch between the
ClientApp registry and the API validators.

Which side is wrong

The frontend is right; the API validator is the bug:

• report.inquiry_sample.foundation_depth sits on the report.height domain
  — the same one as construction_level, groundwater_level_temp, mason_level.
  The genuine measures (concrete_charger_length, pile_distance_length) sit on
  report.length.
• The risk model computes foundation_depth - groundwater_level - 0.6
  (FunderMapsWorker sql/model/recreate_model_risk_dynamic_all.sql:184), which is
  only meaningful if both are on the same datum. groundwater_level_temp is
  unambiguously NAP: 9,925 of 13,812 filled rows are negative, min -44.00.

The legacy C# InquirySample.FoundationDepth [Range(0.0, 999.99)] is simply
wrong. A comment now records that, so it doesn't get "restored" by someone
diffing against the monolith.

Blast radius

• The Webservice never exposed the field.
• The only remaining C# usages are in the retired WebApi path, so there is no
  interaction with the August EOL work.
• No data migration. Only 3 rows ever had a value, and all 3 are junk: an
  all-zeros row plus two test reports named "Cheese" and "Test" (with
  groundlevel of 34 m and 68 m).

Follow-up

PR #98's contract test pins enum mappings only — numeric bounds have no
equivalent, which is why a frontend relabel (ClientApp bceedae, #265,
23 July) could diverge from the validator unnoticed. Worth extending to the
numeric presets once #98 lands.

🤖 Generated with Claude Code