fix(#716): parseerror signature now const char *; drop Pascal-string laundering

[jsavin]

Summary

Closes item 1 of #716 — the langerror.c:167 cast pattern.

The pre-fix call chain laundered a real C string through a Pascal-typed parameter for no reason:

yyerror(const char *s)            <- yacc gives us a NUL-terminated C string
    parseerror((ptrstring) s)     <- cast to Pascal type to match the (wrong) decl
parseerror(bigstring bs)
    copyctopstring((const char *) bs, bscopy)  <- cast back so strlen "works"

The 2025-12-09 Codex comment on line 164 even said it out loud: "bs is a C string from yacc/lex". The type label was lying.

This PR drops the cast pair and makes the signature honest:

• parseerror takes const char * (matches runtime_stubs_parser.c and yyerror's own argument)
• the (ptrstring) s cast is dropped at the single callsite (in both langparser.y and the checked-in bison-generated langparser.c)
• copyctopstring (still needed inside parseerror because the downstream lang3paramerror formatter wants a bigstring) now has its boolean return checked, with a log_warn(LOG_COMP_PARSE, ...) on truncation so a >255-byte bison message surfaces rather than silently clipping

Scope

This PR addresses only item 1 of #716. Items 2-6 are independent defects and remain open:

• 2: strings.c push-after-copy truncation
• 3: shellsysverbs.c getenv unboundedness
• 4: langsqlite.c errmsg sites
• 5: tcpverbs.c / WinSockNetEvents.c INDIRECT sites
• 6: db.compactDatabase YAML coverage (may fold into Behavioral test coverage for copyctopstring deep-stack defenses (#712 follow-up) #715)

Adjacent audit

langerror.c contains no other bigstring/cstring cast patterns. Across the project:

$ rg 'copyctopstring\(\(const char \*\)' Common/source Common/headers portable frontier-cli tests
(no matches)

Test plan

• make build — clean (6 pre-existing warnings, none new)
• make unit (./tools/run_headless_tests.sh) — 589/589 pass (was 586; +3 new in parser_tests)
• Direct ./tests/parser_tests — 12/12; the [parse-WARN] parseerror: yacc message exceeded 255 bytes and was truncated line is observed on the >255-byte direct-call test, confirming the new truncation surface works
• cd tests && make test-integration — 2186 pass / 21 baseline failures (matches the baseline stated in PR test(#715): behavioral coverage for copyctopstring deep-stack defenses #717's commit log; the 21 failures are pre-existing html/tcp/startup flakiness, no parse/langerror failures)
• Audit search: rg 'copyctopstring\(\(const char \*\).*bigstring|copyctopstring\(\(const char \*\)' ... returns zero hits

Regression coverage shape

Three new cases added to tests/parser_tests.c:

1. test_parseerror_short_message_does_not_crash — compile "1 + " → yacc emits a short syntax-error message → exercised end-to-end
2. test_parseerror_long_token_does_not_crash — 300-byte identifier + trailing operator → forces the bison error path with a long token name embedded
3. test_parseerror_direct_long_message_well_defined — calls parseerror directly with a 350-byte C string; verifies the truncation-log warning fires in a well-defined manner

These would have compiled and run pre-fix (the cast pair was a round-trip), so they're regression guards against someone "tidying" the signature back to bigstring — which would silently re-introduce the laundering pattern.

🤖 Generated with Claude Code