Reply to every debugger request, even the ones that finish later

Eight events answered nothing at all: cpu.stepping, cpu.resume, gpu.stats.feed
and the five stepping requests. Their documented contract was "no immediate
response, an event follows", which leaves a client unable to tell an accepted
request from one that was dropped - and forces any request/response
correlation to carry a hardcoded list of events that don't answer. wsdbg's
--sync doesn't have that list, so it waits for the next message and treats
whatever broadcast arrives first as the answer, silently misattributing every
later response in the script.

Fixed centrally in the dispatch loop rather than in the eight handlers: if a
handler finishes without having sent anything, send an empty response carrying
its ticket. That also covers handlers added later, which is the part a
per-handler fix wouldn't.

The asynchronous event that reports the real outcome is unchanged and still
follows. The two are easy to tell apart - the acknowledgement carries the
ticket from the request, a broadcast has none:

  -> {"event":"cpu.stepInto","ticket":3}
  <- {"event":"cpu.stepInto","ticket":3}
  <- {"event":"cpu.stepping","pc":142622896,"reason":"cpu.stepInto",...}

Existing clients ignore events they didn't ask for, and this adds a message
rather than changing or removing one, so nothing that worked before breaks.

pspautotests 314/314.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9

Core/Debugger/WebSocket.cpp

@@ -224,6 +224,14 @@ void HandleDebuggerRequest(const http::ServerRequest &request) {
 		if (eventFunc != eventHandlers.end()) {
 			eventFunc->second(req);
 			if (!req.Finish()) {
+				// The handler arranged something that finishes later - a step, a resume, a stats
+				// feed - rather than answering now. Acknowledge it anyway, so that *every* request
+				// gets exactly one reply. Without this a client can't tell "accepted, wait for the
+				// event" from "dropped on the floor", and any request/response correlation has to
+				// special-case a list of events that don't answer. The event that actually reports
+				// the result (cpu.stepping, and so on) still follows.
+				req.Respond();
+				req.Finish();
 				// Poll more frequently for a second in case this triggers something.
 				highActivity = 1000;
 			}