fix(extract): truncate comments/docstrings at UTF-8 character boundaries

[DeusData]

Closes #1017

Bug

extract_comment_text (extract_defs.c) capped over-long comments/docstrings with a raw byte cut — text[MAX_COMMENT_LEN] = '\\0' — which splits a multi-byte UTF-8 character straddling byte 500 and leaves an incomplete sequence. That value lands verbatim in nodes.properties: syntactically valid JSON but invalid UTF-8, so any consumer decoding the SQLite TEXT column strictly (Python's sqlite3, the default for anyone building tooling on the exported DB) throws on read. Never surfaced on English-only code (single-byte chars cut safely anywhere); reproduces on Japanese/Chinese/etc. comments — reporter hit it on EC-CUBE.

Fix

Snap the cut back over UTF-8 continuation bytes (10xxxxxx) to the lead byte of the straddling character and terminate there, dropping the partial character — result is always valid UTF-8. The reporter also noted the append_json_string escape loop as a possible defense-in-depth site; I confirmed the primary corruption is here (the atomic-precheck prevents the escape loop from firing on a value that passed it), so this is the single root-cause fix.

Reproduce-first

python_docstring_utf8_boundary_truncation_issue1017 builds a docstring with 3-byte CJK chars (E3 81 82 = U+3042 あ) straddling the 500-byte cap and asserts the captured docstring decodes as valid UTF-8 via an inline validator. RED before (mid-char split → invalid), GREEN after. End-to-end verified: the stored nodes.properties for the fixture goes from Python-sqlite3-unreadable to valid UTF-8.

Verification

Full local suite 6334 passed, 1 skipped; lint-ci clean.

[DeusData]

Superseded by #1094, which landed the same UTF-8 codepoint-boundary snap-back for docstring/comment truncation first — thank you @harshitaajoshi for the clean fix and the thorough boundary test. Closing this in favour of yours (merged as e2d41d9).