Parents: #495, #473 Regression follow-up to: #672 Related: #696
Problem
DOMFormData__forEach projects file names through Value.asStr(), treating the StringCell physical backing bytes as canonical WTF-8. With flat Latin-1 storage enabled, a non-ASCII file name such as café.bin is exposed as an invalid one-byte sequence instead of the same JavaScript string. The borrowed ZigString conversion then fails and silently truncates callback iteration. Entry names and string-valued entries already use representation-aware conversion; file names are the remaining asymmetric path.
Every Promise, stack, queue, job, Worker, and shared Map/Set iterator surface is explicitly excluded and remains user-owned.
Scope
- Make FormData file-name extraction representation-aware and OOM-correct.
- Preserve native blob pointer identity, callback order/count, stable borrowed ZigString lifetime, rooting/reentrancy, and the pinned Bun/Home ABI symbols and layouts.
- Keep canonical/ASCII storage allocation-free; only physical flat Latin-1 requires bounded conversion.
- Add a non-ASCII private-ABI fixture that fails under forced flat storage before the fix.
No-workaround rules
- No global flat-storage disable, lossy replacement, invalid-byte acceptance, duplicate persistent filename copy, ABI fork, or input-specific special case.
- No Promise, stack, queue, job, Worker, or shared Map/Set iterator changes.
Acceptance
- Bun-compatible DOMFormData callbacks preserve an exact non-ASCII filename in Debug, forced-flat Debug, ReleaseSafe, and TSan.
- Native blob identity, callback sequence, entry names, string fields, and JavaScript-created Blob/File integration remain exact.
- Home and Bun private-ABI audits/fixtures remain exact with no symbol or layout changes.
- Focused and full unit gates pass; this private boundary flips 0 applicable Test262 cases.