core-host: count a Project memory entry in code points, not UTF-16 units #1886

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: da971a34345e4fd293ac299aff869220
Branch: dev/1-p257-memory-code-points
Base: 575accc
At: 2026-10-31T02:54:18Z

What happens today

MAX_ENTRY (600) is compared against String#length, which counts UTF-16 code units, not characters. Every non-BMP character (emoji) costs two units, so a short emoji note is refused as "over 600 characters".

Reproduced through the real endpoint (rt.projectEndpoint, host started from main at 575accc63bc42b3becd2003601126d2409b417fb):

The refusal leaves no row behind (decisions stays empty), so a 350-character note simply cannot be saved, and the message about "600 characters" is wrong in both directions.

Where the unit is counted

• core/src/host/store.js:521 — if (entryText.length > MAX_ENTRY) inside appendProjectMemory, the one door every writer goes through (The memory box accepts empty and over-long text and reports Memory saved., while the assistant's own writer refuses both #1847).
• core/src/host/project-assistant.js:191 — if (entry.length > MAX_ENTRY) in the assistant writer.
• core/src/host/constants.js:25-26 — the MAX_ENTRY comment names the bound but not its unit.

Expected

• Count code points: [...text].length — the rule the repo already uses (core/src/host/chat-index.js:26, core/src/host/busy-ack.js:71).
• 600 accepted and 601 refused, in both writers and in the store, on the same unit.
• The MAX_ENTRY comment states the unit is code points, not UTF-16 units, so the next writer cannot reintroduce String#length.
• The refusal message stays A Project memory entry is at most 600 characters (the panel and the tests key off it): an emoji note of 601 code points is refused, 600 is stored.

Red first (must be red on 575accc6)

A test that uses emoji, not ASCII filler:

• 350 × 😀 is stored (today: refused) — this is the user-visible one;
• 601 code points refused, 600 stored;
• the existing ASCII 600/601 case stays green;
• the assistant writer and the store agree (same entry accepted by both).

Scope

core/src/host/store.js, core/src/host/project-assistant.js, core/src/host/constants.js (comment), their tests, the patches/ds-bot/files/… mirrors, one changelog.d fragment with the issue link.

Not in scope: grapheme clusters (a ZWJ family emoji still costs 7 code points — the decided rule is code points, not display columns); the message wording; the client-side counter (separate issue).

Dedup

grep -rn "MAX_ENTRY" core/src and a closed-issue search for emoji / code point found no issue about the counting unit; #1847 and #1881 fixed empty and over-long entries but kept UTF-16 counting.

Verification

npm run verify green at the tip (or the two touched suites plus the touchpoints), patches check three lines ok, mirrors byte-identical (cmp), base 575accc6.