feat(assembly): warn when a joint primitive drives a placed part

[w1ne]

Follow-up to #686, which I closed as a misdiagnosis. This is the fix that case actually needed.

The problem

Two conventions for a joint's origin, both correct within their own path:

	origin means	child geometry	composition
.revolute() / .prismatic() / .ball()	parent→child frame offset (URDF)	modeled about its own origin	T(o) . M
.mate() + connector(...)	a pivot point	modeled where it sits	T(o) . M . T(-o)

Mixing them is silent. Model a part in place — box(50, 10, 8).translate(5, 15, 12), the obvious thing to write — then drive it with .revolute(), and the engine correctly applies link-frame semantics to in-place geometry. The child ships displaced by the joint origin at every pose, including 0:

Model     arm  [ 5, 15, 12] .. [55, 25, 20]
Exported  arm  [10, 35, 28] .. [60, 45, 36]     (production STL, elbow: 0)
Delta          [+5, +20, +16]  ==  the joint origin

evaluate returns ok: true with zero diagnostics. Worse, the downstream gates then score the displaced solids: swept-collision reported a clean 0–90° sweep on a hinge that self-collides at 30° as authored. A wrong green is worse than a red.

I hit this with the whole repository in front of me, misread it as a solver bug, and shipped a "fix" that broke the robotics stack. A customer with only the MCP tools has strictly less to go on.

The gate

assembly.joint.child-modeled-in-place (warn), fired only when both hold:

1. the joint origin is non-zero — at a zero origin the conventions agree exactly, so nothing can be displaced;
2. the child was positioned by the script, via part(..., { at }) or a placement transform on its own top-level shape.

A correctly-authored URDF link is modeled about its origin and placed by the joint alone, so it trips neither condition. The hint names both exits rather than assuming which convention the author meant.

Wiring

The gate runs before validateAssemblyWithMates's no-mates early return. An assembly built from joint primitives has zero mates by construction, so anything placed after that return never sees a joint-primitive scene — exactly the case this checks. My first draft sat after it and was dead code; the last test in the spec drives the real validator entry point so it cannot silently come unwired again.

(Worth noting separately: that early return is also why joint-primitive assemblies get so little validation, and is likely behind review_cad reporting mechanism: broken / orphan-part on a sound joint-primitive assembly.)

Verification

• 8 tests: two positive forms, plus four false-positive controls — a URDF-authored link, a zero origin, a mate-based assembly, and a link built from translated primitives (interior construction is not placement).
• Negative control: stubbing the gate to return [] fails exactly the 3 positive cases and the wiring test, leaving all 4 controls green.
• tests/ tree: 3367 pass. src/ suites: 2006 pass. tsc --noEmit clean. The one red file locally is viteReviewLiveEndpoint.test.ts — Cannot find module '../lightningcss.darwin-arm64.node', the known darwin-only env issue, unrelated and untouched by this change.
• Catalogue 247 → 248. The two count assertions had stale titles reading 245; titles now match their assertions.