Two fastify request-JSON parity tests crash under --filter json, tracked by nothing

[proggeramlug]

test_issue_1240_fastify_request_json and test_issue_1293_fastify_request_json crash (not parity-fail) under the parity harness's --filter json selection. Both are fastify HTTP-server tests.

Found incidentally while re-measuring #7478 on the pinned quiet mini: 35 tests matched --filter json, 33 passed, 0 parity-failed, and these 2 crashed. Reproduced on the mini's unmodified origin/main checkout, so they are pre-existing and were not caused by the change under test (a docs-only diff).

Why this is worth a ticket rather than a note

Neither test appears in test-parity/known_failures.json or gap_snapshot.json, so nothing tracks them and nothing goes red on them. They are also not in the 12 test_gap_*json* tests that the JSON work routinely runs — they only surface under a broader --filter json, which is why a whole campaign of JSON work (#7477, #7483, #7499, #7537, #7539, #7546, #7478) never saw them.

A crash is a stronger signal than a parity failure: it is a wrong answer that could not even finish producing itself. Two of them, in the same subsystem, unattributed.

What to establish first

1. Whether they crash on a dev host too, or only on the mini — the mini's toolchain differs (it carries z3 4.16 and needs install_name_tool repointing for the compiler driver, per the gc-ratchet artifact's provenance notes).
2. Whether the crash is in fastify's request handling or in JSON parsing reached through it. If the latter, it belongs with the tape work; if the former, it is an HTTP-server bug that merely mentions JSON.
3. Whether they ever passed — git log on the test files plus a spot-check at an older tag would say whether this is a regression or has never worked.

Do not add them to known_failures.json before (3): that file is a ratchet since #7599, and an entry without a known provenance is the suppression it replaced.

[proggeramlug]

Closing — not a crash, and my filing was wrong. These two tests do not crash; they refuse to compile under PERRY_NO_AUTO_OPTIMIZE=1, deliberately and with an explicit message:

error: `import 'fastify'` is not supported with PERRY_NO_AUTO_OPTIMIZE: the prebuilt
stdlib is not compiled with `external-fastify-pump`, so fastify requests would never
drain (the request loop hangs). The in-stdlib fastify adapter was removed; build
without PERRY_NO_AUTO_OPTIMIZE so the stdlib is rebuilt with the fastify pump wired in.

Compiled the way the test actually requires — no PERRY_NO_AUTO_OPTIMIZE — test_issue_1240_fastify_request_json.ts builds at exit 0, zero errors, and runs: Server listening on http://0.0.0.0:18997. It is a long-running wire-level server test with its own driver (test-files/run_test_issue_1240.sh, which POSTs and asserts on the response), so a bare invocation correctly sits in its request loop until killed.

The real finding is a harness trap, and it is mine. I have been putting PERRY_NO_AUTO_OPTIMIZE=1 in every agent brief — it avoids ~1 GB of target/perry-auto-* per compile, which is a real problem (one agent minted 34 of them and filled the volume). But it makes every fastify test fail with the refusal above, and a broad --filter json sweep picks exactly those up. That is what produced the '2 crashes' report this issue was filed on.

So there is nothing to fix in the tests. Two things worth carrying instead:

1. The refusal message is doing its job well — it names the missing feature (external-fastify-pump), the consequence (the request loop would hang), and the fix, rather than failing at link time or hanging. That is why this was diagnosable in one compile.
2. A sweep that sets PERRY_NO_AUTO_OPTIMIZE=1 should either exclude the auto-opt-requiring tests or report them as skipped rather than failed. Filed separately if it recurs; not worth a ticket on the strength of one sweep.

Thanks to the #7478 re-measure for surfacing it — the observation was accurate, my interpretation of it was not.