fix: don't let kill() short-circuit stop()

[connortechnology]

Split out of the investigation in #5029 — independent of the mode=single question there,.

kill() cleared this.started before calling this.stop(), but stop() returns early when !started:

} else if (!this.started) {
  console.warn(`... has already stopped.`);
  return;
}

For the zms path that meant the clearInterval() calls for statusCmdTimer and streamCmdTimer never ran, activePlayer was never reset, and mediaStream/audioTrack/videoTrack were never released. Every kill() leaked a pair of live intervals, which adds up on a montage or Watch page cycling monitors every few seconds.

This keeps started set until stop() has done its work, and passes skipStreamCommand so stop() doesn't follow CMD_QUIT with a CMD_STOP aimed at a socket zms is already tearing down. The connkey is cleared afterwards instead of before.

stop() already sets started = false and activePlayer = '' at the end, so kill() no longer needs to.

The new parameter is optional and every existing caller invokes stop() with no arguments, so behaviour is unchanged for them.

Testing: npx eslint web/js/MonitorStream.js clean. Not exercised against a live stream — worth a sanity check on a montage page.