fix(stdio): route bridge debug logs to stderr to keep MCP JSON-RPC framing clean

Fixes AnkleBreaker-Studio/unity-mcp-server#11 — "Windows Codex transport
closes after successful Unity MCP connect on read-only tool calls".

Root cause
----------
Two call sites used `console.debug(...)` which writes to stdout in Node.
The MCP stdio transport reserves stdout exclusively for framed JSON-RPC
messages. Any non-JSON data there corrupts the framing:

  - strict clients (Codex CLI) validate framing and close the transport
    on the first invalid chunk;
  - lenient clients (Claude Desktop / Claude Code) tolerate unknown
    messages and keep working, which is why the bug escaped detection.

The two offending log sites were on the hot code path that every bridge
call goes through, so any tool routed to Unity after the first call
would kill the transport on Codex.

This explains the exact symptoms reported on the issue:

  - unity_list_instances, unity_select_instance, unity_editor_ping all
    succeed — they are served entirely server-side and never reach the
    queue-submission path.
  - unity_scene_info, unity_editor_state fail with "Transport closed" —
    they are the first calls that submit to the Unity queue, hit the
    debug log, and corrupt stdout.

Fix
---
Replace both `console.debug(...)` with `console.error(...)` so the
diagnostic lines go to stderr where they belong. No functional behavior
changes, queue mode stays active for everyone.

Files:
  - src/unity-editor-bridge.js : queue submit log
  - src/tool-tiers.js          : lazy-loading log

Verified end-to-end
-------------------
Reproduced the bug on Codex CLI 0.122.0 against the unfixed server:
list_instances + select_instance succeed, scene_info + editor_state
fail with "Transport closed". Re-ran the exact same scenario after the
fix — all four calls succeed. Regression-checked on Claude: no change
(queue mode still in use, all tools continue to work).

Note: SABERBOY's proposed workaround in the issue (force legacy mode
by flipping _useQueueMode and _queueModeDetermined at the top of
unity-editor-bridge.js) avoids the buggy code path but disables queue
mode wholesale, losing multi-agent fairness and the graceful
domain-reload handling it provides. This change addresses the actual
root cause and preserves queue mode.