fix(websocket): stop LogCallbackEvent broadcast recursion in shutdown

[AdaInTheLab]

Summary

EventBroadcaster.Initialize subscribed to LogCallbackEvent with e => Broadcast("LogCallback", e). Broadcast's catch block called Log.Warning(...) on failure. On 7DTD, Log.Warning fires another LogCallbackEvent through the same bus → re-enters this subscriber → Broadcast throws again → Log.Warning again → infinite recursion → stack overflow → KC crashes.

The throw is reliably reproducible during shutdown: once the WebSocketServer manager has stopped, _server.WebSocketServices...Broadcast(json) raises "The current state of the manager is not Start." Observed live on a Windows prod box — 65+ minutes after a botched auto-start, KC's GracefulRestart wedge cascade ended in "Error in event handler for LogCallbackEvent: The requested operation caused a stack overflow." repeated dozens of times in the log, crashing KC and forcing a service auto-restart.

Fix, scoped narrowly to the LogCallbackEvent path

1. [ThreadStatic] _inLogBroadcast re-entrancy guard. Only on the LogCallback path — other event types don't loop back into the logger from their failure handler, so they keep the existing Log.Warning-on-failure to surface real broadcast bugs.

2. Pulled the LogCallbackEvent subscriber out into a named BroadcastLogCallback method so the guard logic stays readable instead of being inlined in a lambda. Sets the flag, calls Broadcast, clears the flag in finally.

3. Broadcast<T> gains a suppressFailureLogging parameter. When true (LogCallbackEvent path), the catch falls back to Console.Error.WriteLine instead of Log.Warning so the failure notification itself cannot fire a fresh LogCallbackEvent and restart the recursion. Wrapped in its own try/catch in case stderr is also unhappy during shutdown.

The dropped log-broadcast on re-entry is the right tradeoff: we'd only be re-entering because Broadcast just failed, which means the ws clients aren't going to see this log line anyway. Better one lost diagnostic line than a crashed service.

On testing

No unit test included. EventBroadcaster is a static class tightly coupled to WebSocketSharp.Server and the 7DTD Log type (already called out as game-runtime-only in ModEventBusTests.cs:97). The actual recursion only happens when _server is non-null AND Broadcast throws, neither of which is reachable from the existing test harness without restructuring the class. The fix is small and the failure mode is reproducible in vivo — verifying the absence of recursion in prod logs after deploy is the better signal.

Test plan

• Build passes on Windows .NET Framework 4.8
• Deploy to prod box (72D-ADA → kitsuneden-prod)
• Trigger a GracefulRestart and confirm no "stack overflow" lines in log
• Confirm WS clients still get log broadcasts during normal operation

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!