fix(core): invisible format chars U+206A-U+206F pass both Unicode sanitizer pipelines

[0xMudit]

What happened

Six invisible Unicode format characters — U+206A–U+206F (INHIBIT/ACTIVATE SYMMETRIC SWAPPING, INHIBIT/ACTIVATE ARABIC FORM SHAPING, NATIONAL/NOMINAL DIGIT SHAPES) — pass through both sanitizer regexes in packages/core/src/text-sanitize.ts:

• BIDI_FORMAT_REGEX (line 60) covers U+2066–2069 but skips its immediate neighbors U+206A–206F
• ZERO_WIDTH_REGEX (line 72) covers U+2060–2064 but also skips U+206A–206F

All six are category Cf — invisible, zero-width, deprecated bidi-related formatting characters, squarely in the threat family these classes exist to strip. They are not whitespace, so the \s+ collapse doesn't remove them either. Live-reproduced with the exact pipeline from sanitizeUnicodeText:

input:  "alice\u206Abob"
output: "alice\u206Abob"   (invisible char survives)

Two names differing only by U+206A render identically but compare unequal. Session names, foreign titles, ids rendered verbatim, and digest payloads all share these classes ("single source of truth", per the file's own comments), so the gap is systemic. The foreign id guard FOREIGN_UNSAFE_CHARS (packages/core/src/foreign-session.ts:156) has the same gap.

No test covers U+206A–206F, so this looks like unintentional drift rather than policy.

How to reproduce

normalizeUserSessionName("alice\u206Abob") → { ok: true, value: "alice\u206Abob" } — an invisible character persists; the same string also passes isSafeForeignId.

Suggested fix

Add \u206A-\u206F to BIDI_FORMAT_REGEX (space replacement keeps word separation consistent with the other bidi controls) and to FOREIGN_UNSAFE_CHARS. A follow-up class decision could also consider variation selectors (U+FE00–FE0F) and tag characters (U+E0000–E007F), both known invisible-content vectors.

[Sma1lboy]

I can take this.

Dev design: extend BIDI_FORMAT_REGEX in text-sanitize.ts from ⁦-⁩ to ⁦-, and make the same extension to FOREIGN_UNSAFE_CHARS in foreign-session.ts. Space replacement keeps these consistent with the other bidi controls. The second edit is not optional: that constant's own doc comment calls it "one source of truth" with the sanitizer, so fixing only one side would recreate exactly the drift the comment exists to prevent.

Scope / non-goals: no change to the zero-width class, and no action on the variation selectors (U+FE00–FE0F) or tag characters (U+E0000–E007F) the issue raises as a follow-up — those are a separate class decision and deserve their own issue rather than being folded in here.

Test plan / acceptance: a RED regression asserting all six code points are stripped by sanitizeForeignText and rejected by isSafeForeignId, plus controls pinning that already-covered neighbours (U+2069, U+2060, U+202E) stay stripped.

Reproduction on current main:

cp       name                            survives_sanitize  id_guard_accepts
U+206A   INHIBIT SYMMETRIC SWAPPING      true               true
U+206B   ACTIVATE SYMMETRIC SWAPPING     true               true
U+206C   INHIBIT ARABIC FORM SHAPING     true               true
U+206D   ACTIVATE ARABIC FORM SHAPING    true               true
U+206E   NATIONAL DIGIT SHAPES           true               true
U+206F   NOMINAL DIGIT SHAPES            true               true

surviving_sanitize=6/6  accepted_by_id_guard=6/6

Confirming the issue's reasoning about why the whitespace collapse never caught these: /\s/.test() is false for every one of them.

Two notes on scope:

• What this does and does not prove. The reproduction shows the characters pass both pipelines. It does not construct an attack — that needs an assumption about who controls session names, which I would rather not invent. I will keep the PR description within what the evidence actually shows.
• Overlap with test(core): unit-test the shared Unicode sanitizer #3692. That PR adds packages/core/src/__tests__/text-sanitize.test.ts covering the existing bidi set, not this range. I plan to put my regression in foreign-session.test.ts next to the existing sanitizeForeignText tests, since it needs to assert the id-guard side too. Happy to rebase onto test(core): unit-test the shared Unicode sanitizer #3692 and add the case to its new file instead if a maintainer prefers the coverage consolidated there.