[asdf80730]

Fixes #393
Fixes #417
Fixes #456

Deleting a phrase that holds a character the Windows console cannot encode — 髙, 㩐, 栞, 湾 — did nothing at all in the 詞庫編輯 page, while the dialog kept reporting 刪除詞彙成功. UserPhraseHandler.post() printed the request's own phrase data to the console before its two loops (print("add", added, "remove", removed)); on a console using a legacy code page that print raises UnicodeEncodeError, so tornado answered 500 and the delete loop never ran — #456 posts the traceback for exactly that line, and #393's reporter found the same by commenting it out. Two further layers hid the failure: result started from a success default of 1 and was then only overwritten by whichever library call happened to run last, so an item that failed was masked by a later item that succeeded (#417), and onRemovePhrase's complete: callback ignored the response entirely and alerted success unconditionally.

• python/input_methods/chewing/config_tool.py: both debug prints are gone — the POST handler's along with the GET handler's print(chewing_ctx, ret) — so phrase data never reaches the console.
• Every userphrase_add/userphrase_remove return is now consulted. In the libchewing this tree pins (libchewing/ @ 452f622), chewing_userphrase_add returns 1 on success and 0/-1 on failure, and chewing_userphrase_remove returns the rows it actually deleted (sqlite3_changes, 0 when the phrase is not found), so anything below 1 is reported as a failure, and a failure latches: it can no longer be masked by a later success. The old comment # 0: error, 1: success, default to success describes neither contract and is replaced.
• python/input_methods/chewing/js/user_phrase.js: onRemovePhrase reads {"result": ...} the way onAddPhrase already does, treats a non-200 as a failure too, and reloads the table either way — a batch that deleted only some rows no longer keeps showing the deleted ones until a manual refresh.
• 罕用字使新酷音詞彙刪除失敗 #417 also asks for a switch to turn 自動產生詞彙 off; that is a separate feature and is untouched here.

在「編輯使用者詞庫」刪除含罕用字（髙、㩐、栞、湾）的詞彙其實完全沒生效，對話框卻一直顯示成功。原因不在輸入法，而在詞庫編輯伺服端：config_tool.py 在刪除迴圈之前把整包詞彙資料 print 到 Windows console，舊式 code page 遇到編碼不進去的字就拋 UnicodeEncodeError，該次 POST 直接 500、刪除動作一步都沒跑（#456 的 traceback 正是該行；#393 的 reporter 把它註解掉後就刪得掉）。回傳給前端的 result 又是以成功為預設值、只被最後一個呼叫覆寫，前端也完全不檢視回應就彈成功訊息，所以三張單其實是同一個 root cause。本 PR 拿掉那些 debug print、逐一檢查每個 libchewing 回傳值，並讓刪除對話框顯示真實結果；#417 另要求的「自動產生詞彙」開關屬另一功能，未一併處理。煩請回報者在下一個 beta 版重測這三組詞。

Validation:

• tests/verify_windows.sh against an integration tree carrying these identical product files: 21 layers passed, 0 failed (bundled python.exe backend suite 153 tests OK with 4 platform skips; Node, Go plus the Windows/386 cross-build, Rust fmt/clippy, C++ helper tests).
• The delete-loop regression seam tests/test_chewing_user_phrase_editor.py (the project's internal suite) replays that return table against a stubbed ChewingContext and an ASCII-hostile stdout: 5 tests OK against this branch's exact tree — rare characters 髙/㩐/栞 through add and remove, a failing removal followed by a succeeding one, -1 from remove, a failing add beside succeeding removals, and an enumerate that reports its rows without printing them.

Architecture and design by asdf80730. Implementation generated with AI assistance from omp (tensorfold/Qwen3.8-Flash-Next).

[asdf80730]

The first workflow run from this fork branch is queued awaiting maintainer approval (jobs: 0, run 41065021878) — could a maintainer approve it?

Everything verifiable without a build has been run on this exact tree (0c0e68a): the 21-layer local Windows gate passes (0 failed), and the delete-loop regression seam — rare characters 髙/㩐/栞 through add/remove against a stubbed context and an ASCII-hostile stdout — is 5/5 green.

(Comment generated with assistance from omp (tensorfold/Qwen3.8-Flash-Next))