[PCMan]

Fixes #937

Summary of Changes

• Returns a safe fallback dummy service { textReducer, response } from the createServer callback in node/server.js when a service is not found or not yet initialized.
• Answers with { success: false, seqNum: ... } cleanly rather than throwing a fatal error.

Rationale

In nime's requestHandler.js, service default destructuring does not trigger when service is explicitly null. Any request arriving before init previously attempted null.textReducer(), causing an unhandled fatal TypeError that crashed the entire Node server. Returning a fallback dummy service prevents the crash without modifying upstream node_modules.

Generated with assistance from Antigravity (Gemini 3.8 Flash)

[ilwu]

用系統 node v24 直接跑 node/server.js，以 stdin/stdout 餵請求（與 PIMELauncher 相同），對照 master (1458cea)：

情境	master	本 PR
正常：meow init → onActivate → filterKeyDown	OK	OK
init 用不存在的 GUID，再送 onActivate	TypeError: Cannot set properties of undefined (setting 'isKeyboardOpen')，process 結束	init 回 {"success":false}，onActivate 回 {"success":false}，process 活著，另一個 client 的 meow init 正常
沒 init 就直接送 onActivate	TypeError: Cannot read properties of null (reading 'env')，process 結束	一樣會結束（同樣的 TypeError）

第二個情境是 nime nimeServer.js 在 lineHandler 裡幫新 client 建了 {service: null, state: null}，之後 handleClientRequest 直接丟給 handleRequest，這條路不經過 createServer 的 callback，所以本 PR 的 fallback service 碰不到它。正常流程 DLL 一定先 init，但後端被 launcher 重啟時既有 client 的請求就是這個樣子（#909 之後 launcher 會主動斷線讓 client 重新 init，所以機率已經低很多）。若要一起補，在 handleClientRequest 裡遇到 connections[clientId].service == null 時回 {success:false, seqNum} 就可以。

#946 與 #955 修的是同一條路徑，行為在這組測試裡完全一樣。

(測試腳本與本留言由 Claude Code (Claude Fable 5.1) 協助產生)