feat(commands): add a fun command category with 18 public rs commands

Adds a `fun` category to the operator command registry, reachable identically
from site chat and Discord:

- text: bonk, hug, slap, 8ball, roll, coin, ship, rate, uwu, wanted
- counters: bonkboard, pet, snitch
- hardware: honk, boo, spin, disco, vibecheck

Supporting pieces:

- `permission: 'public'` in the registry. The dispatcher previously decided
  non-admin access with a hardcoded chain of `action !== '...'` comparisons, so
  every new public command needed a dispatcher edit. That chain is replaced by a
  registry lookup plus SELF_GATED_ACTIONS, which names the commands that enforce
  their own permissions internally (goal/reason are read-public write-admin;
  verify/deter reject non-lockdown-admins themselves). Existing behavior for
  every pre-existing command is unchanged.
- `cooldowns.js`, a per-actor per-command in-memory gate. Site chat's own rate
  limit is per-socket-per-message and does not bound a specific command, so
  without this one person could turn `rs honk` into a siren. Site chat rebuilds
  its router per message, so the gate is created at module scope there and
  injected.
- `funStatsService`, a small JSON store for the persistent tallies. Counters are
  keyed by an actor key spanning transports (`user:<id>` / `discord:<id>`), and a
  Discord id has no row in `users`, so `user_feature_state` could not hold them
  without violating its foreign key.

Safety notes:

- `issueCommand` is the raw rover transport and performs none of the ownership,
  deterrence, or private-safety checks the socket `command` handler applies, so
  honk and spin re-check `canDrive` themselves and spin re-applies
  `applyPrivateDriveSafety`. Both are therefore site-chat only: a Discord message
  has no socket and can never satisfy those checks.
- `boo` speaks a canned taunt rather than caller-supplied text, so it cannot
  become an unmoderated TTS channel aimed at whoever is nearest a rover.
- `disco` obeys the existing room-light lock and the homeAssistant feature gate.
- The whole fun category is suspended in lockdown mode.
- Mute and deterrence already stop command-shaped chat before the router runs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

server/src/services/chatService/textCommands.js

@@ -25,8 +25,10 @@ const {
 } = require('../verificationService');
 const { publishEvent } = require('../eventBus');
 const assignmentService = require('../assignmentService');
+const funStatsService = require('../funStatsService');
 const { loadConfig } = require('../../helpers/configLoader');
 const { createCommandHandlers } = require('../operatorCommandService');
+const { createCooldownGate } = require('../operatorCommandService/cooldowns');
 const { parseCommandText } = require('../operatorCommandService/config');
 const { createWebTransportHandlers } = require('../operatorCommandService/webTransport');
 const { commandReplyToText } = require('./commandResultFormatter');
@@ -39,6 +41,14 @@ const {
 const config = loadConfig();
 const discordConfig = config.discord || {};
 
+/*
+  Site chat builds a fresh command router for every message so each router can
+  close over the sending socket. Fun command cooldowns therefore have to live out
+  here: a gate created inside the router would be thrown away after one message
+  and would never actually rate limit anything.
+*/
+const commandCooldowns = createCooldownGate();
+
 function isTextCommand(text) {
   return parseCommandText(text, config).matched;
 }
@@ -120,6 +130,12 @@ function createChatCommandRequest({ socket, text, sendSystemMessage }) {
     actor: {
       bot: false,
       id: socket.id,
+      /*
+        Fun command tallies are keyed by identity rather than connection, so the
+        canonical user id is passed alongside the socket id. Without it a user's
+        bonk count would reset on every reconnect and split across browser tabs.
+      */
+      userId: String(socket?.data?.userId || '').trim() || null,
       label: nickname,
       isAdmin: isAdmin(socket),
       isLockdownAdmin: isLockdownAdmin(socket),
@@ -185,6 +201,16 @@ async function runChatTextCommand({ text, socket, sendSystemMessage }) {
     muteUser,
     unmuteUser,
     sanitizeMentions,
+    funStatsService,
+    commandCooldowns,
+    /*
+      Fun commands that move hardware need the sending socket so they can prove
+      the caller holds control. issueCommand is required lazily for the same
+      reason replayEngineV2 is: commandService registers socket handlers on load,
+      and chatService should not pull that forward in the boot order.
+    */
+    getActorSocket: () => socket,
+    issueCommand: (roverId, payload) => require('../commandService').issueCommand(roverId, payload),
     sendToChannel: null,
     isAdminUser: (id) => String(id) === String(socket.id) && isAdmin(socket),
     isLockdownAdminUser: (id) => String(id) === String(socket.id) && isLockdownAdmin(socket),