fix(extrusion-hyperobject): align extrusion_length source default with manifest

[aldoruizluna]

What changed

The PARAM fallback for extrusion_length in all three CadQuery entry files now equals the manifest default.

param	mode	manifest default	source literal (before)	source literal (after)	file:line
extrusion_length	rail	100	150	100	rail.py:15
extrusion_length	frame	100	150	100	frame.py:15
extrusion_length	module_track	100	150	100	module_track.py:15

Direction and why

The source literal now follows the manifest default. Studio always sends the manifest-resolved set, so users already see 100 mm. The .scad twins (rail.scad, frame.scad, module_track.scad, which no mode references) also say extrusion_length = 100. Only the CadQuery fallbacks disagreed. A bare-default render now builds 100 mm bodies instead of 150 mm. The body count stays 1.

How this maps to GOC-1

GOC-1 (Digital Twins MES, Phase 2) variables.json is complete only once yantra4d injects every declared parameter (RENDER_INJECT_FULL_PARAMS). This PR removes the three default-drift notes for this cartridge (the rule comes from hyperobjects-spec#30). After it, turning that flag on cannot change this cartridge's geometry for callers that send {}.

Evidence

Tooling: hyperobjects-spec at 510efba (the #30 branch). CI pins 3ff3736, which lacks the rule. CadQuery 2.8.0 on macOS.

# main (faaea08), --render --no-printability
y4d-spec check: cartridges=1 failures=0 notes=6 geometry=verified renders=11 presets=8 skipped=0
   (3 x default-drift extrusion_length, 3 x preset 'standard_rail' renders identical to defaults — it sets 150, which equalled the drifted literal)

# this branch
$ y4d-spec check ./extrusion-hyperobject --render --require-openscad --parity --openscad-path libs --openscad-path .
  ok extrusion-hyperobject (./extrusion-hyperobject, 11 render(s) verified (8 preset), no comparable pair)
  note ... (frame, frame, preset 'decaying_rail', cadquery): renders geometry identical to the default-params render ... despite setting degradation_state, extrusion_length, profile_scale
  note ... (module_track, module_track, preset 'decaying_rail', cadquery): renders geometry identical ...
y4d-spec check: cartridges=1 failures=0 notes=2 geometry=verified renders=11 presets=8 skipped=0 parity=0/0 ok, warn=0, exempt=0, placement=0, failures=0

Pre-existing issue now visible (left out of scope)

The two remaining notes are real but existed before this change:

• degradation_state is declared visible_in_modes: [rail, frame, module_track], but only rail.py reads it. In frame and module_track it does nothing.
• decaying_rail now differs from the defaults only by degradation_state: 5, so it renders identically there.

Two possible fixes, for a separate one-cartridge PR:

• narrow visible_in_modes for degradation_state to [rail], or
• have frame and module_track read it.

This PR does not touch verification. It changes one cartridge and three files.

macOS green is not proof (AGENTS.md rule 4). The CI Linux render lane decides, and it is pending at the time of writing.

CI status (updated)

Linux CI on this head: manifest conformance (all cartridges): pass; render (cartridges changed in this PR) (extrusion-hyperobject): pass; render scope (which cartridges changed): pass.

🤖 Generated with Claude Code