feat(commands): play a bonk sound on the bonked user's rover

`rs bonk` now publishes a `fun.bonked` event carrying the rover the target is
currently driving, and a new audioForwardService listener plays a sound file on
it. Wired as an event rather than a direct call so the command layer stays
unaware of ffmpeg, matching how the charging-complete cue is already done.

The sound file goes at `server/assets/bonk.wav` and is NOT committed here. Note
that `server/assets` is the correct home rather than `server/public`: the webui
builds to `../server/public` with `emptyOutDir: true`, so anything stored there
is deleted by the next build.

Details:

- The audio is rate limited per rover on a 20s window, separate from the 4s text
  cooldown. Playback interrupts whatever that rover is forwarding, including a
  live microphone, so a group of people cannot chain it against one driver.
- No sound plays if the target is not currently driving, is not a real user, or
  is the caller themselves. The text bonk and the tally still work in all cases.
- A missing sound file logs once and skips, so the command works on a server that
  never installs one. A playback failure is caught and logged rather than
  surfacing as a failed chat command.
- Discord bonks play the sound too; only commands needing the caller's own socket
  are unavailable from there.

Server suite: 138 passing, 0 failing.

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

server/src/services/chatService/textCommands.js

@@ -203,6 +203,9 @@ async function runChatTextCommand({ text, socket, sendSystemMessage }) {
     sanitizeMentions,
     funStatsService,
     commandCooldowns,
+    // Lets `rs bonk` announce itself so audioForwardService can play the bonk
+    // sound on the rover the target is driving.
+    publishEvent,
     /*
       Fun commands that move hardware need the sending socket so they can prove
       the caller holds control. issueCommand is required lazily for the same