docs(blog): add final project report for bitcoinfuzz-infra

[devSuryansh]

Summary

Final project report for Summer of Bitcoin 2026, covering my work on bitcoinfuzz-infra: a control plane that launches, supervises and monitors fuzzing campaigns for the bitcoinfuzz differential fuzzer.

Follows my midterm post, Infrastructure for the Fuzzer That Finds Bitcoin's Bugs (#21). Where that post described what I was setting out to build, this one explains the delivered system and the engineering decisions behind it.

What the post covers

• The problem: bitcoinfuzz could only be trusted while somebody was watching its stdout, so crashes and stalled campaigns went unnoticed.
• Target discovery, and why the registry parses the fuzzer's own docker-compose.yml instead of duplicating the target list.
• The eight-state campaign lifecycle, and why an explicit state machine caught edge cases that a status string would have hidden.
• Resource-aware admission control: campaigns are admitted against a CPU and memory budget rather than launched on request.
• Managing containers from inside a container, including Docker socket group ownership and why passing a container path to the host daemon silently creates an empty volume instead of failing.
• Turning libFuzzer's pulse output into nine Prometheus metrics, and why the crash metric has to be a Counter rather than a Gauge.
• Crash detection, its attribution limitation when two campaigns share a target, and the five Alertmanager rules.
• Restart behavior: Docker as the source of truth for running containers, SQLite for everything else, and why queued campaigns are the hard case.

Checklist

• Author profile already present in _config.yml
• Filename follows YYYY-MM-DD-title.md
• Front matter complete, categories drawn from the approved list
• Code samples quoted from the source repository
• Links tested