URDF.UR5's gripper_link_index=7 is a hardcoded position, not a stable identifier

Migrated from `tech-debt.md` (deleted, see repo history via `git log -- tech-debt.md`).

`URDF.UR5`'s `gripper_link_index=7` is a hardcoded position, not a stable identifier. `UR5.__init__` calls `super().__init__("ur5", ..., gripper_link_index=7)` -- a raw positional index into the parsed link list meant to mark the gripper/tool attachment link.

Already bit once: `robot_descriptions` 3.0.0 changed which upstream repo `"ur5"` resolves to (`Universal_Robots_ROS2_Description` instead of whatever 2.0.0 pointed at), and the two versions parse to different link counts (11 vs. 13) and orderings -- index `7` moved from the intended attachment point onto `wrist_2_link`, a real arm joint, silently dropping 2 of 6 joints from `self.n`. **Immediate fix already applied:** pinned `robot_descriptions>=2.0,<3.0` in `pyproject.toml`, restoring known-working data. This does not fix the underlying fragility, just stops it firing today.

**Confirmed a name/structure-based fix is viable:** comparing the full raw link lists between the two `robot_descriptions` versions, all 6 real arm joints have identical names/`isjoint` status in both. Only the gripper-attachment link's name differs (`ee_link` in 2.0.0 vs not present in 3.0.0), but `tool0` exists in **both** -- just at a different index (9 vs. 12). A name-based lookup (`"tool0"`) or a structural one ("first fixed link after the last actuated joint") would survive this exact upstream change.

**Proposed fix:** replace `gripper_link_index: int` with a lookup that doesn't depend on absolute position -- match by a small set of known tool-frame names (`tool0`, `ee_link`, `flange`, ...) with a fallback, or derive structurally. Worth checking how many other `URDF.*` models pass a raw `gripper_link_index` the same fragile way before deciding on the general fix -- UR5 is likely not unique.

[]