Parent: #473 Regression follow-up to: #683 Related: #689, #691
Problem
Response construction now stores statusText from canonical semantic WTF-8, but Response.prototype.clone() reads the stored String Value back through Value.asStr() and passes those physical bytes into a canonical string constructor. With flat Latin-1 storage active, cloning a response whose status text contains caféÿ republishes invalid physical bytes and the clone no longer preserves the original JavaScript string. The original response remains correct, which leaves the clone-only edge outside the #683 witness.
Every Promise, stack, queue, job, Worker, and shared Map/Set iterator surface is explicitly excluded and remains user-owned.
Scope
- Route cloned status text through the representation-aware canonical WTF-8 boundary.
- Preserve status, headers and their guards, body cloning/disturbance rules, type, URL, redirected state, prototype, source immutability, exception ordering, and OOM propagation.
- Keep canonical/ASCII storage borrowed; only physical flat Latin-1 performs bounded conversion.
- Extend the existing Response StringData witness so the exact old clone path fails under forced flat storage.
No-workaround rules
- No flat-storage disablement, eager global canonicalization, replacement characters, duplicate persistent status-text copy, alternate Fetch implementation, hidden retry, or input-specific special case.
- No Promise, stack, queue, job, Worker, or shared Map/Set iterator changes.
Acceptance
- A Response clone preserves exact non-ASCII statusText under canonical and forced-flat storage.
- Source statusText, headers, null-body state, status, type, URL, and redirected fields remain unchanged.
- Focused Debug, forced-flat Debug, ReleaseSafe, and TSan pass, followed by the full unit gate.
- Test262 Web API inventory is reported exactly; no unsupported corpus claim is made.