fix: Use a byte-class table for the string escape scan in jwriter

[kinyoklion]

SDK-2888

writeQuotedString scans for the next byte that needs escaping with a range check and two equality comparisons per byte. The Go compiler emits that as multiple compare-and-branch pairs per byte, which caps the throughput of the one-byte-per-iteration scan loop; a 256-entry byte-class table is a single always-L1-resident load plus one branch, and is the technique the reader-side tokenizer rewrite uses. This converts the writer's scan to the same idiom. Output is byte-identical.

The table is deliberately not shared with jreader's (in the reader-side rewrite, #52): the predicates differ at both ends. The reader's decode path treats control characters as plain (the lenient read side passes them through verbatim) while this writer must escape them, and it stops at bytes >= 0x80 (its escape-decoding path re-encodes runes) while this writer copies multi-byte characters through verbatim. A shared-table variant using per-package bit flags measured performance-neutral (-0.04%), so each package keeps its own four-line generated table rather than gaining an internal cross-package dependency. Each table's comment notes the contrast.

Benchmarks

go1.24.3, linux/amd64, interleaved A/B (3 rounds x count 2, benchstat n=6):

                        │ comparisons │            table            │
WriteString-16            45.99n ± 3%   46.53n ± 5%  ~ (p=0.937 n=6)
WriteArrayOfStrings-16    4.309µ ± 2%   4.006µ ± 2%  -7.02% (p=0.002 n=6)
WriteObject-16            132.0n ± 3%   124.6n ± 2%  -5.61% (p=0.002 n=6)
geomean                   296.8n        285.3n       -3.88%

The single-short-string case is flat (fixed per-call overhead dominates); the win appears wherever string scanning is a meaningful share of the work. For context, the same table-vs-comparisons choice measures much larger on the reader side (+7% to +40% for the comparison chain), where the scan loop is a bigger fraction of total time.

Testing

Full suite passes including with -race; golangci-lint clean; BenchmarkWriteObjectToNoOpWriterNoAllocs remains 0 allocs/op. The cross-permutation writer suite exercises the new scan against the same expected encodings, including every escape class and multi-byte content.

---

Note

Overview
writeQuotedString now decides whether a byte can be copied verbatim using a 256-entry plainStringChars table instead of a per-byte range check plus comparisons for " and \.

The table marks bytes from 0x20 through 0xFF as plain except quote and backslash, so UTF-8 multibyte sequences pass through unchanged (unlike the reader’s table, which is documented as intentionally separate). Encoded JSON output is unchanged; benchmarks show modest gains when string scanning dominates (e.g. arrays of strings, objects).

^{Reviewed by Cursor Bugbot for commit 8e8f17e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kinyoklion]

When working on the read performance we had a similar shape and a LUT was a clear win in comparison. So I tested it out on the writer and it was also a win here.