fix(editor): stop Monaco outlining fullwidth CJK punctuation

[PathGao]

Closes #186. Closes #94. First half of #393; the z-family half (#104) is left
alone, per your "can get to the other Monaco defaults at a later date" on #393.
You queued this one — "if we can fix the punctuation highlights we can queue it"
— the day before v2.7.0, and it did not make the release.

monaco.editor.create has never passed unicodeHighlight; there is no
occurrence anywhere in the repo, so Monaco's defaults have been in charge for
the editor's whole life. ambiguousCharacters defaults to true, and ， ！
？ （ ） ； ： are each a confusable of an ASCII counterpart, so each
gets a box. That default is right for source code, where a character that looks
like ASCII but is not is an attack vector, and wrong for a Markdown editor whose
users write prose.

Why it looks intermittent

The highlight is suppressed when the word around the character is entirely
non-ASCII — shouldHighlightNonBasicASCII in
common/services/unicodeTextModelHighlighter.js returns early on "no basic
ASCII, and something obviously non-ASCII present". So pure CJK is clean and the
boxes appear only once basic ASCII shares a word with the punctuation:

line	boxed by default
你好，世界。（测试）！？	nothing
使用 Monaco，然后保存。	，
安装依赖（npm ci），再运行测试。	（ ） ，
打开 Settings：Editor，字体大小。	： ，
**粗体**，*斜体*，`代码`。	， ，

The last row is the one that makes this unavoidable: no Latin word is needed,
because a Markdown emphasis marker is itself basic ASCII. Mixing Latin technical
terms into CJK prose is the normal case, not an edge one.

Scope

One sub-option, ambiguousCharacters: false. The rest are deliberate:

invisibleCharacters stays at its default. A stray zero-width space or NBSP
is a real hazard in Markdown — an NBSP after - stops the list from parsing —
and unlike the punctuation it is never something the author typed on purpose. It
is the part of this feature that earns its place in a prose editor, and
unicodeHighlight: false would have taken it with the boxes.

nonBasicASCII needs no setting. It defaults to the inUntrustedWorkspace
sentinel, which resolves through !trusted, and standalone Monaco's
StandaloneWorkspaceTrustManagementService.isWorkspaceTrusted() returns true
unconditionally — so it is already off. Were it on, every ideograph would be
boxed rather than the punctuation, which is not what either reporter described.
Pinning it would be a no-op today and would freeze a default you are entitled to
change later.

allowedCharacters was the narrower alternative and is worse. It needs an
enumerated list of every fullwidth form across Chinese, Japanese and Korean
input, and boxes whatever the list forgets.

Unconditional, not gated on language

Monaco already ships the mechanism a language gate would use — allowedLocales,
seeded from the OS locale — and it does not help. 使用 Monaco，然后保存。 boxes
identically under en, zh-CN, zh-Hans, ja-JP and ko-KR, which is why the
reporters saw boxes on CJK systems in the first place. Beyond that, a content or
UI-language gate would make the same file render differently depending on state,
and would flip mid-typing as the first CJK character arrived.

The editor is the only Monaco instance in the app — the preview is a Rust
render_markdown HTML pipeline and there is no diff editor — so there is nowhere
else to apply this. editor.updateOptions merges and does not pass
unicodeHighlight, so setting it once at creation holds.

Tests

Four tests in editorOptionWiring.test.ts. They execute the option object
rather than matching the source for a string, which matters here: asserting that
"ambiguousCharacters" appears in Editor.svelte says nothing about which
characters Monaco ends up outlining, and that is the whole contract. The literal
is lifted out of the real monaco.editor.create call with the TypeScript parser,
evaluated, merged over Monaco's shipped defaults through
EditorOptions.unicodeHighlight.applyUpdate, and run through
UnicodeTextModelHighlighter — the function that decides what gets a box. A
regression has to survive Monaco's own code to reach the assertions.

One of the four asserts the fixtures still reproduce the bug once the option is
taken away, so a Monaco upgrade that changed the confusable set fails loudly
instead of leaving the other three quietly asserting nothing.

Reverting only the option, keeping the tests:

✖ the editor turns off ambiguous-character highlighting and nothing else
  AssertionError: exactly one sub-option is overridden
  + actual - expected
  + undefined
  - { ambiguousCharacters: false }

✖ no box is drawn on fullwidth CJK punctuation
  AssertionError: nothing outlined in CJK prose, got
    ["，","（","）","，","，","：","，","，","，","（","）"]
  11 !== 0

ℹ pass 9   ℹ fail 2

Replacing it with a blanket { ambiguousCharacters: false, invisibleCharacters: false, nonBasicASCII: false } instead reddens the other direction — "the
invisible-character warning survives the fix" and the narrowness assertion — so
the pair pins the fix from both sides.

scripts/monacoInternals.d.ts is the one judgement call I would flag. Monaco
ships declarations for its public API only, so driving the option registry and
the highlighter from a test needs types for two internal module paths.
Declaring them narrowly rather than as any means a shape change is a type
error and a moved module is a loud import failure; the alternative was to give
up on executing Monaco's real logic and go back to a source-text assertion.

Verification

npm audit, npm run check (0 errors, 644 files), npm test (681 pass), and
cargo test all green.

Visually: I rendered Monaco 0.55.1 with this exact option object against the
document above, with and without the fix. Default gives 11 unicode-highlight
decorations; with the fix, 1 — the zero-width space, still flagged, which is the
point of keeping invisibleCharacters. To be precise about what that was: real
Monaco in a browser with the same options, not the packaged Tauri app, which
does not run outside its webview (__TAURI_INTERNALS__ is undefined).

Co-authored-by: Claude Opus 5 noreply@anthropic.com