feat(geometry): honor IfcSweptDiskSolid StartParam/EndParam (#606)

The swept-disk solid processor read attribute 1 (Radius) but ignored
attributes 3 (StartParam) and 4 (EndParam) entirely. Files where the
directrix is an IfcCompositeCurve or IfcPolyline and the trim params
restrict the sweep to a sub-range of the curve rendered the whole
curve instead — most visibly in rebar models from Revit/Tekla, where
a 2 m bar declared as IFCSWEPTDISKSOLID(#dir, r, $, 0., 1.) over a
3-segment composite curve rendered as 12 m with all the end-hooks
unfolded into the bar.

Dispatch now honors trim parameters for the two directrix types
whose IFC parameterisation is unambiguous from the entity:

  - IfcCompositeCurve (and subtypes via is_subtype_of): segment-
    index based, each segment contributes 1.0 to the parameter.
  - IfcPolyline: point-index based, each segment between consecutive
    points contributes 1.0.

Boundary segments are truncated by linear interpolation along the
sampled polyline — exact for piecewise-linear input, an approximation
for curved parents (acceptable for rebar). Out-of-range params clamp;
inverted (start >= end) ranges return an empty mesh. Other directrix
types (IfcLine, IfcCircle, IfcTrimmedCurve, IfcBSplineCurve) still
ignore trim — their parameterisations are length / angle / knot-based
and need separate handling — flagged as a known limitation.

Adds 11 unit tests in profiles::tests covering: full-range identity,
exact-half boundaries, strict-interior comparisons, two-point partial
trim, fractional multi-segment trim with dedup, out-of-range clamping,
inverted ranges, SameSense=F reverse-then-trim semantics, and direct-
polyline-directrix paths.

Author: joepaddock-uk

.changeset/swept-disk-trim-params.md

@@ -0,0 +1,14 @@
+---
+"@ifc-lite/wasm": patch
+---
+
+Honor `IfcSweptDiskSolid.StartParam` / `EndParam` for `IfcCompositeCurve` and `IfcPolyline` directrices. Previously these were silently ignored, so a swept disk solid like `IFCSWEPTDISKSOLID(#dir, 0.0095, $, 0., 1.)` with a 3-segment composite-curve directrix swept the entire curve instead of just segment `[0,1]` — most visible in rebar models authored by Revit/Tekla, where bars rendered 3-5× their real length with end hooks unfolded into the bar geometry.
+
+The dispatch now honors trim parameters for the two directrix types whose IFC parameterisation is unambiguous from the entity:
+
+- `IfcCompositeCurve` (and subtypes via `is_subtype_of`): segment-index based, each segment contributes 1.0 to the parameter.
+- `IfcPolyline`: point-index based, each segment between consecutive points contributes 1.0.
+
+Boundary segments are truncated by linear interpolation along the sampled polyline (exact for piecewise-linear input). Out-of-range params clamp; inverted ranges (`StartParam ≥ EndParam`) produce empty geometry. Other directrix types (`IfcLine`, `IfcCircle`, `IfcTrimmedCurve`, `IfcBSplineCurve`) still ignore trim — their parameterisations are length / angle / knot-based and need separate handling — flagged as a known limitation.
+
+Adds 11 unit tests in `profiles::tests` covering: full-range identity, exact-half boundaries, strict-interior comparisons, two-point partial trim, fractional multi-segment trim with dedup, out-of-range clamping, inverted ranges, `SameSense=F` reverse-then-trim semantics, and direct-polyline-directrix paths.

rust/geometry/src/processors/swept.rs

@@ -48,15 +48,46 @@ impl GeometryProcessor for SweptDiskSolidProcessor {
         // Get inner radius if hollow
         let _inner_radius = entity.get_float(2);
 
+        // StartParam / EndParam (optional IfcParameterValue). Per IFC spec, when the
+        // directrix is an IfcCompositeCurve the curve is parameterised so that segment
+        // index `i` covers parameter range [i, i+1]. Without honoring these, files that
+        // intend e.g. only the first segment to be swept render every segment — the
+        // common rebar case where a 2 m bar reads as 12 m with hooks unfolded.
+        let start_param = entity.get_float(3);
+        let end_param = entity.get_float(4);
+
         // Resolve the directrix curve
         let directrix = decoder
             .resolve_ref(directrix_attr)?
             .ok_or_else(|| Error::geometry("Failed to resolve Directrix".to_string()))?;
 
-        // Get points along the curve
-        let curve_points = self
-            .profile_processor
-            .get_curve_points(&directrix, decoder)?;
+        // Get points along the curve, honoring trim parameters where the directrix's
+        // parameterisation is well-defined and obvious from the entity:
+        //   - IfcCompositeCurve (and IfcCompositeCurveOnSurface): segment-index based,
+        //     each segment contributes 1.0 to the parameter.
+        //   - IfcPolyline: point-index based, each segment between consecutive points
+        //     contributes 1.0 to the parameter.
+        // Other directrix types (IfcLine, IfcCircle, IfcTrimmedCurve, IfcBSplineCurve)
+        // have length-, angle-, or knot-based parameterisations and fall back to the
+        // full sampler. Files using those with explicit StartParam/EndParam will still
+        // render the full curve — flagged as a known limitation.
+        let has_trim = start_param.is_some() || end_param.is_some();
+        let curve_points = if has_trim
+            && directrix.ifc_type.is_subtype_of(IfcType::IfcCompositeCurve)
+        {
+            self.profile_processor
+                .get_composite_curve_points_trimmed(
+                    &directrix,
+                    decoder,
+                    start_param,
+                    end_param,
+                )?
+        } else if has_trim && directrix.ifc_type == IfcType::IfcPolyline {
+            self.profile_processor
+                .get_polyline_points_trimmed(&directrix, decoder, start_param, end_param)?
+        } else {
+            self.profile_processor.get_curve_points(&directrix, decoder)?
+        };
 
         if curve_points.len() < 2 {
             return Ok(Mesh::new()); // Not enough points