Stream the rig library to the client

The core rig reader landed its reading half but not its exposing half:
the bindings shipped (`base_rig`, per-change `rig`) while the library
they are references INTO stayed server-side on LoadedSloppak.rigs with
no consumer at all. A client could see that a change binds
"grand-piano" and had no way to learn what that was.

Add a `rigs` WS message carrying the library whole and verbatim, and put
each drum part's resolved `tones` binding on its `song_info.drum_parts`
entry — the drum half had the same gap, since the loader resolved the
binding in P3 and the wire payload was still `{id, name}`.

Sent whenever the pack ships a library, deliberately NOT gated on this
arrangement having tone changes: a pack can bind sound to its drum parts
alone via `drum_tones` and still need the library.

Verbatim matters here. Core selects no realization and applies no
`intent.gm` floor, so the consumer that voices the part needs the whole
block to make that choice — including the unknown `role`/`engine`/`kind`
values and `ext` namespaces §7.9 requires a Reader to preserve.

Client side: `hwState.rigs` / `toneBaseRig`, `getRigs()` /
`getToneBaseRig()`, and `bundle.rigs` / `bundle.toneBaseRig` so
renderers reach them the same way they reach every other chart array,
with both reset paths clearing them between songs.

Packs that bind no rig are byte-identical on the wire — no `rigs`
message, no `base_rig`, no `rig`, no `tones` on a drum part.

Signed-off-by: gionnibgud <gionnibgud@gmail.com>

CHANGELOG.md

@@ -8,6 +8,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ## [Unreleased]
 
 ### Added
+- **The rig library reaches the client.** Completes the core reader for source
+  rigs: a new `rigs` WebSocket message carries the pack's `rigs.json` library
+  verbatim, and each entry in `song_info.drum_parts` now carries its `tones`
+  binding. Previously the *references* shipped (`base_rig`, per-change `rig`)
+  with nothing to resolve them against — the library loaded server-side and had
+  no consumer. The library is sent whenever a pack ships one rather than being
+  gated on the arrangement having tone changes, since a pack can bind sound to
+  its drum parts alone. `highway.js` exposes `getRigs()` / `getToneBaseRig()`
+  and adds `bundle.rigs` / `bundle.toneBaseRig` for renderers. Core still
+  selects no realization and applies no `intent.gm` floor — that belongs to
+  whatever voices the part. Packs that bind no rig send byte-identical frames.
 - **Core reader for source rigs (feedpak 1.18.0).** A pack can declare what a
   MIDI part should sound like by binding a rig; core now reads that binding and
   hands it to the client instead of dropping it. Three parts: the