A dimension defaulted from `undef` passes at exit 0, and no channel can refuse it without refusing correct parts

[CameronBrooks11]

Found while narrowing #286's markers in PR #306, and deliberately left uncovered there. Epic #305.

What is wrong

#286 made check and measure refuse a build whose stderr names a name the engine could not resolve. A different shape produces the same silent damage and is not covered: an expression whose type error makes OpenSCAD substitute a default into a dimension.

o = undef;
h = o + 1;
linear_extrude(h) square([40,30]);

The engine prints one warning and exports a clean, watertight, single-solid mesh:

WARNING: undefined operation (undefined + number) in file uo.scad, line 2
facets: 12

linear_extrude receives undef and falls back to a height of 100. Measured with partspec measure:

volume: {"value": 120000.0, "unit": "mm3", "exactness": "exact"}      # 40 x 30 x 100

partspec check with watertight() + solid_count(1):

EXIT=0

The part is 100 mm tall because a name was undefined, and partspec reports it green.

Identical on both pinned engines (2021.01 and 2026.08.01, same warning text, same 12 facets), so unlike #286's include marker this carries no F13 risk.

Why it was excluded from #286

undefined operation is in _UNRESOLVED_MARKERS, but only the four markers that name a name are read on the success path. Guarding the success path on undefined operation was tried in PR #306 and reverted, because it errors correct parts:

holes = 4;
echo("holes: " + holes);          // `+` where str() was meant -- extremely common
difference() { cube([40,30,6], center=true); cylinder(d=8,h=20,center=true,$fn=64); }

That renders a perfect 272-facet part with the bore present, and prints undefined operation (string + number). Refusing it told the reader a name had not resolved and to check OPENSCADPATH — false in every clause. So the marker cannot distinguish "a debug echo has a type error" from "a dimension was silently defaulted", and it is the wrong signal for this.

The right signal

OpenSCAD prints a separate, more specific line at the moment of substitution. Observed alongside the above:

WARNING: Unable to convert cube(size=[undef, 5, 5], ...) parameter to a number or a vec3 of numbers
WARNING: Unable to convert translate([undef, 0, 0]) parameter to a vec3 or vec2 of numbers

Unable to convert names the operation and the substituted parameter directly, and — unlike undefined operation — it fires only where a value actually reached geometry. That is exactly the discrimination the echo case needs.

Smallest fix

1. Measure Unable to convert's wording on both pinned engines before relying on it — An unresolved include or unknown module reports PASS at exit 0; the engine discards stderr on the success path #286's include marker was dead on 2026.08.01 for exactly this reason (Can't open vs Can't find), so treat one engine's string as a guess until the other confirms it.
2. Confirm the echo case does not emit it (my reading is that it does not, since nothing reached geometry there) — that is the whole premise.
3. Add it to the success-path scan, either in _UNRESOLVED_NAME_MARKERS or as its own set with its own message, since the diagnosis differs: not "a name did not resolve" but "a value could not be converted, so the engine substituted a default into a dimension".
4. Pin both engines' spellings in tests/test_openscad_engine.py::test_the_unresolved_markers_match_both_engine_spellings, which already exists for this purpose and needs no engine to run.
5. Note in src/partspec/engines/openscad.py's _UNRESOLVED_NAME_MARKERS docstring that the shape is no longer uncovered — it currently records it as knowingly given up.