Implemented button mapping for the vv3p

[Pochiiko]

Branch is ready (ce64c30, one clean commit on current dev). CI will be
red until PR 1 merges — open as a draft, or wait.

Base:OpenMouse-Project/openmousedev
Head:Pochiiko/openmousevv3p-button-mapping

Remaining steps

1. Rebase onto current origin/dev — done.
2. PR 1 merged.
3. Bump package-lock.json to the merged protocol commit (currently pins
   #b6bce148..., which predates the change). This is the CI fix.
4. Re-run npm run check and npm run size.

Title

feat(razer): add the Viper V3 Pro button mapping panel

Body

Adds the Buttons-tab Mapping card for the Razer Viper V3 Pro.

Important

Blocked on OpenMouse-Project/mouse-protocol#22. CI will fail here until
that lands — MouseStatus.razerButtonMappings and the RazerButton* /
RazerToggle* exports come from it. Once it merges, this needs a
package-lock.json bump to the new protocol commit and CI goes green.

What it adds

• RazerButtonCard (AdvancedCards.tsx) in the buttons tab, laid out with
  button-remap-list/button-remap-row to match MxMasterButtonsCard, the
  other remap card in that tab. Left Click renders as a plain value with an
  explanatory note rather than a disabled select, since it is fixed on the
  Standard layer — Synapse enforces the same restriction.
• applyRazerButtonMapping / applyRazerToggleControl (controller.ts),
  staged through the pending-changes system like every other setting, with
  per-row data-pending-key so a staged row highlights.
• razerButtons in availability.ts, computed from
  status.razerButtonMappings != null. Razer has no BY_FAMILY entry in
  traits.ts — it reaches the advanced section through the
  ui.showAdvancedSection escape hatch — so this reads the driver's field
  directly rather than inventing a family trait.
• Preview fixture mappings, so the card renders in ?preview=razer.
• JS bundle budget 590 → 600 kB. The measured aggregate was 588.2 kB, leaving
  under 2 kB of headroom.

Two control families, one dict

The card renders both families from a single razerButtonMappings dict keyed by
control name. That is safe because the driver guarantees the two families share
no control names and no option labels — there is a test in the protocol PR
asserting exactly that.

The four cross-assignable buttons offer the full mapping list. The three toggle
controls (Scroll Up, Scroll Down, sensitivity button) offer only their own
action or Disabled, because cross-assigning those has never been tested on
hardware and the driver does not expose it.

Verification

• npm run check: build clean, 79/79 tests.
• npm run size: CSS 99%, JS 99%.
• Rendered in ?preview=razer and on real hardware (Viper V3 Pro, 0x00c1
  HyperSpeed receiver, Synapse closed): 7 rows, correct per-family option sets,
  Left Click locked, no console errors.
• Writes confirmed physically through this panel: remapping Mouse Button 4 to
  Right Click made the button open the context menu, and disabling Scroll Down
  stopped the wheel scrolling. Both restored afterwards.

Not included

Hypershift and Scroll Click are not exposed — see the protocol PR for why.

[Pochiiko]

Screenshots of the Button Mapping Feature on VV3P