test_gap_fetch_instanceof_5433 SIGSEGVs, and the gap snapshot launders the crash as an accepted gap (both referenced issues closed) #7526

A SIGSEGV is recorded as an accepted gap

test_gap_fetch_instanceof_5433 segfaults — exit 139, after printing 2 of
its expected lines:

$ perry test-files/test_gap_fetch_instanceof_5433.ts -o /tmp/fi && /tmp/fi
typeof: object
r instanceof Response: true
$ echo $?
139

Reproduced on two hosts (dev Mac and the pinned quiet mini) under --release,
deterministically, at v0.5.1292–1295.

It does not show up as a regression because it is in
test-parity/gap_snapshot.json:

"test_gap_fetch_instanceof_5433": {
  "status": "crash",
  "issue": "5433",
  "added": "2026-07-04",
  "category": "bug-open",
  "reason": "fetch Response/Request instanceof (#5433); standing per #5917."
}

Three things are wrong with that entry

1. A crash is not a cosmetic gap. scripts/run_gap_tests.sh:110 states the
   policy in its own words: "Crashes (SIGSEGV/SIGABRT/timeout) are hard
   defects, never cosmetic gaps." The snapshot exists to hold known output
   divergences so the gate can still catch new ones. Parking a memory-safety
   fault in it converts a hard defect into background noise — and this is the
   only status: "crash" entry in the file, so it is an exception, not a
   convention.
2. Both referenced issues are CLOSED. issue: 5433 → Fetch: new Response()/new Request() — instanceof always false and .constructor is undefined (no prototype link) #5433 closed;
   "standing per parity diff v0.5.1205 → main 2026-07-03: net +32/−10; 10 newly-failing tests need triage (incl. issue-945 guard confirmation) #5917" → parity diff v0.5.1205 → main 2026-07-03: net +32/−10; 10 newly-failing tests need triage (incl. issue-945 guard confirmation) #5917 closed. The entry is marked
   category: "bug-open" while nothing tracks it. Per the lesson from regression: 'class X extends EventTarget' throws 'EventTarget is not a function' (re-breaks #6301, unnoticed because parity is tag-gated) #7518, a
   closed issue whose test still fails is a regression by definition — and here
   the snapshot itself asserts the issue is open.
3. Nothing would notice if it got worse. parity is gated to tag pushes
   only, and within it this test is pre-accepted. A segfault that starts
   corrupting memory earlier, or spreads to neighbouring tests, produces no new
   signal.

What I am not claiming

I have not bisected this and I do not know whether the crash is new since
2026-07-04 or has been there since the entry was added — the entry records
status: "crash" from the start, so most likely the latter. That is worth
establishing, because "we have shipped a known segfault for a month" and "a
cosmetic gap decayed into a segfault" call for different urgency.

Asks

• Root-cause the fault (it is in the fetch Response/Request instanceof
  path — the crash lands after r instanceof Response: true prints, so the
  instanceof itself now works and something later dereferences badly).
• Then either fix it, or — if it must stand — record it somewhere that does not
  launder a crash through the cosmetic-gap channel, with an OPEN tracking issue.
• Consider making run_gap_tests.sh refuse a status: "crash" snapshot
  entry outright, so the policy its own comment states is enforced rather than
  documented.