receipt: add camofox false-success 429 artifact

[SirBrenton]

Summary

Adds a new Pitstop-Truth receipt documenting a false-success acknowledgement failure in Camofox Browser reporting logic.

Canonical receipt:

PT-2026-05-23-github-pr-camofox-3413-429-false-success

---

What happened

sendToRelay in lib/reporter.js treated HTTP 429 responses as successful delivery:

return resp.ok || resp.status === 429;

This caused the runtime to acknowledge successful report delivery even when the upstream relay explicitly rejected the request due to rate limiting.

Under sustained relay throttling, crash reports could be silently dropped while downstream callers received success semantics.

Merged fix:

return resp.ok;

This preserves the never-throws contract while restoring truthful delivery acknowledgement semantics.

---

Why this matters

This receipt expands the corpus beyond retry timing failures into runtime truthfulness failures.

The core issue was not Retry-After handling.

The issue was:

the runtime claimed success despite explicit upstream rejection

This creates:

• silent degradation
• observability blindness
• false operational confidence
• hidden incident risk

The failure generalizes beyond crash reporting:

Any system that overrides upstream rejection semantics can silently corrupt operational truth.

---

Captured topology

signal_origin       = provider
failure_layer       = runtime
decision_layer      = agent
signal_failure_type = overridden
downstream_effect   = silent_degradation

---

Evidence

Primary PR:

• fix: don't treat 429 as success in sendToRelay jo-inc/camofox-browser#3413

Downstream release sync:

• v1.11.0: jo-browser sync + community PRs (May 2026) jo-inc/camofox-browser#4150

---

Validation

python3 scripts/validate_receipts.py
python3 -m json.tool index.json >/dev/null

Result:

OK: validated 66 receipt(s)
ok ✅