Surface curve does not record which pcurve belongs to which surface

[GeneralPawz]

Problem

CurveRelation::SurfaceCurve carries its pcurves as a flat, unordered
associated_geometry: Vec<NodeId>:

SurfaceCurve {
    curve_3d: NodeId,
    associated_geometry: Vec<NodeId>,
    master: MasterRepresentation,
}

A surface curve is the intersection of two surfaces, and each side carries
its own parameter-space image. Which pcurve belongs to which surface is
load-bearing geometric information, and the current model does not record
it: the list is positional at best, and validation accepts any mix.

expect_reference(.., ExpectedReference::CurveOrSurface) is the only
check, so a single-entry list, a swapped pair, or three unrelated nodes
are all equally legal.

Why it matters

Trimming a curved face needs the edge image in that specific surface
parameter domain. With two candidate pcurves and no recorded ownership, a
consumer must guess by re-inverting the surface, which is exactly the
operation the pcurve exists to avoid and is not generally solvable in
closed form.

Exchange formats state the pairing explicitly, so the information is
present at the boundary and is being discarded on the way in.

Done when

• a surface curve records which pcurve belongs to which of its two
  surfaces, rather than an unordered list
• the distinction survives a round trip through the graph
• validation refuses a surface curve whose pcurve/surface pairing is
  incomplete or contradictory, instead of accepting any node mix
• a single-sided surface curve stays expressible: not every edge has two
  parametric sides
• existing SurfaceCurve construction sites migrate, with the master
  representation semantics unchanged

[GeneralPawz]

Landed in 8544c1c.

What changed

associated_geometry: Vec<NodeId> is replaced by a SurfaceSides value that pairs each p-curve with the surface it lies on:

SurfaceCurve {
    curve_3d: NodeId,
    sides: SurfaceSides,
    master: MasterRepresentation,
}

SurfaceSides::single(surface, pcurve) and SurfaceSides::two(s1, p1, s2, p2) are the only constructors, so an unpaired or half-specified side is unrepresentable rather than merely rejected.

Against the acceptance criteria

• Records which p-curve belongs to which surface -- each side owns its (surface, pcurve) pair.
• Survives a round trip -- covered by the_master_can_name_the_second_parametric_side.
• Refuses incomplete or contradictory pairing -- naming the second side as master on a single-sided curve is now GraphError::ContradictoryMaster. Previously expect_reference(.., CurveOrSurface) accepted any node mix; that permissive variant is now gone entirely, and clippy confirmed it had no other user.
• Single-sided stays expressible -- SurfaceSides::single, covered by its own test.
• Existing sites migrated, master semantics unchanged -- the two in-crate sites and the compiler's analytic_directrix test.

The S1/S2 half

MasterRepresentation::ParameterCurve is split into ParameterCurveS1 and ParameterCurveS2. This is the gap that made openbim's IFC lowering refuse IFCSURFACECURVE with two associated p-curves: PCURVE_S1/PCURVE_S2 are positional slots, and with an unordered list there was no honest way to name either, so picking one would have been a guess.

With sides recorded, S1 and S2 name the first and second side exactly. That consumer can now admit the two-p-curve case; that work is in the openbim repo and follows a kernel release.

Verification

Mutation-checked: disabling the contradiction check makes naming_a_side_the_curve_does_not_have_is_refused fail. Workspace 1117 passed / 0 failed at that commit, GATE PASSED.