feat(rig lab): wrists in three axes, and sliders that belong to the pose on screen

Three things the lab could not do.

WRISTS. Each hand had one scalar, a twist about the barrel. That is the only
axis a hand wrapping a cylinder is free in ONCE the arc onto the barrel is
solved — which is true of the support hand, was never true of the trigger hand,
and in neither case left a way to cock a wrist forward or break it inward. Both
now take pitch, yaw and roll, applied in the GUN's frame so the three sliders
mean the same thing whether the muzzle is down at low ready or level down the
sights. Zero is exactly the old behaviour, since the roll term defaulted to zero
too.

HAND POINTS. `gun_stock` and `gun_fore` are the distances along the weapon at
which each hand sits, and they were labelled by what they measure rather than by
whose hand it is. They now say TRIGGER and SUPPORT, next to the off-barrel
shifts for the same two hands, so the four controls that place a hand read as
four controls that place a hand.

POSES. The hold's knobs are now per pose, and the lab shows one pose's at a
time. Half of them mean something different at low ready than down the sights;
showing both sets at once meant every slider on screen was for one of two poses
with nothing saying which. Selecting a pose rebuilds the panel.

Two poses, not four, and deliberately: the runtime blends between exactly two
holds on `ads`. Running and Crouched are locomotion states that still use the
low-ready hold, so they edit the same numbers — and the heading says so, rather
than letting someone tune "Running" and wonder why standing still changed.
Offering four independent tunings would be inventing a capability the code does
not have, and the fourth would silently do nothing.

`pitch` is the case that forced the design: down the sights the muzzle follows
the CAMERA, so there is nothing there to tune. It exists at low ready and
nowhere else, and a spec table where a knob names the poses it applies to is
what lets that be said instead of shipping a control that does nothing.

hold_pose_check asserts both halves — that no pose shows another's knobs, that
aiming offers no muzzle pitch, that the heading names the hold being edited, and
that all twelve wrist axes turn the hand they name.

Its first version reported every wrist axis as moving the hand by 0.0 degrees,
which is precisely the answer it would have given if the wrists had never been
implemented: it read `get_bone_pose_rotation` from a SceneTree script, and Godot
restores every bone's local pose after the modifier pass. The repo has a
reference section about exactly this and it still cost a cycle. Measured through
a PoseProbe, every axis turns its hand ~20 degrees.

Co-Authored-By: Claude Opus 5 <[email protected]>

.claude/skills/character-pipeline/references/verification.md

@@ -46,6 +46,7 @@ Two related traps:
 | `rig_anchor_check.gd` | a grip anchor physically moves the weapon, and clears | 0 failures |
 | `anchor_shift_check.gd` | the hand anchors move in the GUN's frame, both poses | 0 failures |
 | `anchor_drag_check.gd` | dragging a marker writes the knob the mouse asked for | 0 failures |
+| `hold_pose_check.gd` | the lab shows only the selected pose's knobs; every wrist axis turns its hand | 0 failures |
 | `anim_capture.gd` / `orbit_capture.gd` | renders, for looking | — |
 | `roster_capture.gd` | one photo of every character, from the picker | — |
 | `ui_capture.gd` | one photo of every menu screen | — |
@@ -88,6 +89,11 @@ Three of these exist because the obvious check passes on a broken system.
   it hangs off and rotating into the current gun basis cancels the breathing,
   the ADS blend and the recoil kick exactly, because all three move the basis
   and the anchor together.
+- `hold_pose_check` measures the wrists through a `PoseProbe`, and had to learn
+  it the same way everything else did: reading `get_bone_pose_rotation` from the
+  SceneTree reported every wrist axis as turning the hand by **0.0 degrees** —
+  the identical answer it would give if the wrists had never been implemented.
+  See READ THIS FIRST. That trap is still the most expensive one in this repo.
 - `surface_class_check` FAILS on a surface that falls through to the heuristic
   instead of resolving from the table. A model whose names stopped matching still
   renders — the fallback catches it — and quietly loses its per-class art