fix(hypergraph): build a slider from a prismatic node in to_mechanism

[HugoFara]

Closes #56.

A slider-crank did not survive Linkage.to_hypergraph() → to_mechanism(): it assembled, then jammed as soon as the crank turned.

from_sim_linkage tagged only LinearActuator nodes PRISMATIC; an RRPDyad (or PPDyad) output stayed REVOLUTE. Its guide is a hyperedge over the two line anchors and the slider, which the clique expansion from #55 turns into two extra neighbours. The dyad's output is now tagged PRISMATIC — it is the slider block — and compute_mobility reports 1 DOF for the slider-crank instead of 0.

to_mechanism built every driven node from its first two solved neighbours as two Links regardless of joint_type, so the slider became an RRR dyad pinned to a ground node at its initial distance. A PRISMATIC node is now read the way from_sim_linkage writes it: one edge to its revolute anchor, one 3-node hyperedge for the line. It becomes a PrismaticJoint with axis / line_point taken from the two line nodes and a single link to the anchor, scheduled once that anchor is solved.

The round trip reproduces Linkage.step() to ~1e-15 over a full cycle (the issue's reproducer is now a test).

Mechanism only holds a slide line fixed to the frame, so the cases it cannot represent raise NotImplementedError with a reason instead of mis-solving: a guide on a moving link, a PPDyad-style double slider, a prismatic node with no guide hyperedge.

Not in scope, noted for later:

• from_mechanism still drops the slide line of a PrismaticJoint (it has no joints on the line to hang a hyperedge on), so slider_crank() → from_mechanism → to_mechanism fails as before.
• A LinearActuator driver node is still built as a revolute crank by to_mechanism.
• The mechanism's indeterminacy() counts a ground joint that only sits on the ground link as a revolute pair, so it reports −1 for the round-tripped slider-crank; compute_mobility on the hypergraph is right.