fix(Delete): guard against negative prevTok on leading-comma input (OSS-Fuzz 4649128545288192)

[buger]

Summary

• Fixes OSS-Fuzz testcase 4649128545288192 — Delete panicked with runtime error: index out of range [-1] on malformed inputs that begin with a stray comma (e.g. ,{"test":1{}, ,""{"test":0}).
• Adds native go test -fuzz wrappers around the existing OSS-Fuzz targets in fuzz.go, with panic-recover crash recording, so local fuzzing can find many distinct crashes per run instead of stopping at the first.
• Adds run_fuzz_campaign.sh, an iterating multi-pass campaign runner that stops once a full pass produces no new unique crash signatures.

Root cause

When Delete removes the last sibling of an object, it reassigns keyOffset to the offset of the preceding sibling-separator comma returned by findTokenStart. On malformed input with a garbage leading comma at offset 0, findTokenStart returns 0 → keyOffset = 0 → prevTok = lastToken(data[:0]) = -1 → the subsequent data[prevTok] reads index -1 and panics.

Fix

Guard the data[prevTok] dereference. When prevTok < 0 there is no content before the key, so newOffset = 0 is the natural answer.

-if remainedTok > -1 && remainedValue[remainedTok] == '}' && data[prevTok] == ',' {
+if prevTok > -1 && remainedTok > -1 && remainedValue[remainedTok] == '}' && data[prevTok] == ',' {
     newOffset = prevTok
-} else {
+} else if prevTok > -1 {
     newOffset = prevTok + 1
+} else {
+    newOffset = 0
 }

Test plan

• go test ./... — full suite passes
• Two new regression cases added to deleteTests covering the OSS-Fuzz repro and the variant the local fuzzer produced
• 2-minute / 76 M-exec re-fuzz of Delete after the patch finds zero crashes
• Full multi-target fuzz campaign across all 14 OSS-Fuzz targets (~2.85 B execs) saturated with only this single bug surfacing

🤖 Generated with Claude Code