[proggeramlug]

Summary

Fixes #1767 — SIGSEGV in js_buffer_from_value reached from @perryts/mysql's executePreparedNow on the first parameterized query.

Root cause

Perry's Small String Optimization stores strings of length 0..=5 inline in the NaN-box payload under SHORT_STRING_TAG (0x7FF9) instead of a heap StringHeader.

js_buffer_from_value gated the string path on is_string(), which is STRING_TAG-only (0x7FFF) and returns false for inline SSO values. So a short-string argument fell through to the pointer-extraction path (bits >> 48 >= 0x7FF8 matches 0x7FF9), where its inline bytes were masked to 48 bits and dereferenced as an ArrayHeader*.

The fault address from the repro was 0x056f676e616d — literally the bytes m a n g o plus the SSO length byte 0x05, i.e. the 5-char apiKey "mango" interpreted as a pointer.

This is a regression: before SSO, "mango" was a heap StringHeader and Buffer.from handled it. It became reachable in @perryts/mysql's prepared-statement param encoder (Buffer.from(v, 'utf8')) once the #1663 microtask fix let execution get that far.

Fix

• Extract the byte-slice → buffer encoding match from js_buffer_from_string into a shared buffer_from_str_bytes(bytes, encoding) helper.
• Add an is_short_string() branch to js_buffer_from_value that decodes the inline bytes via short_string_to_buf and routes them through that helper, so heap and inline strings share identical hex/base64/latin1/utf8 semantics.

Testing

• Two new runtime unit tests (buffer_from_value_decodes_sso_short_string_{utf8,hex}) covering empty + 1..=5-byte SSO values.
• Full buffer:: test module green (15 tests); cargo fmt --all -- --check clean.
• End-to-end: compiled the issue's repro4.ts against @perryts/mysql@0.1.4 + a local MySQL. Before the fix it SIGSEGVs on the first POST (backtrace matches the issue exactly); after the fix it survives repeated sequential POSTs, inserts rows, and the 401 / non-SSO-key paths still work — verified with both default (auto-optimize) and --no-auto-optimize builds.