funding: add coverage-guided fuzz harness for the channel-opening state machine

[MPins]

Overview

This PR adds FuzzFundingManagerFSM, a native Go coverage-guided fuzz harness that exercises the funding manager's channel-opening state machine end to end. It decodes the corpus byte stream into a sequence of
events driving one or more concurrent funding flows against the manager.

Design

• Single shared SUT, per-flow counterparty. Alice (the system under test) is one shared *Manager; each flow gets its own counterparty (Bob) manager. The SUT is what we're testing, so all adversarial or inconsistent values are imposed by the counterparty and the SUT must validate/reject them — as originator the SUT only ever emits valid values.
• FSM over a byte stream. Events (start-as-funder, start-as-fundee, switch-flow, peer-interaction, confirm-funding-tx, …) and their parameters are read from the fuzz input, so the fuzzer explores interleavings of concurrent flows.
• Deterministic oracles. Reservation counts are asserted at fixed handshake barriers; adversarial injections must never advance the live handshake; a premature channel_ready must be parked, not opened.

[github-actions]

🟢 PR Severity: LOW

Classified from file diff | 1 file | 2034 lines changed

🟢 Low (1 file)

• funding/fuzz_test.go - New fuzz test file (*_test.go); test-only change, no production code touched

Analysis

This PR consists solely of a new file, funding/fuzz_test.go, adding 2034 lines with no deletions. Although funding/* is normally a CRITICAL package (channel funding workflow coordination), the file matches the *_test.go pattern, which the classification rules explicitly designate as test-only content regardless of package path — placing it in the LOW severity tier ("best-effort review").

Since this is the only file in the diff and it's a test file, it's also excluded from the file-count/line-count bump calculation (0 non-test files, 0 non-test lines changed), so no severity bump applies.

No production code in funding/* is modified — this PR only adds fuzzing coverage for that package.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}

[Bartok9]

Review

Thanks for investing in a real coverage-guided funding-state fuzz harness — this is high-value (channel open is a classic adversarial surface) and matches the spirit of growing fuzz coverage rather than only happy-path unit tests.

Concept ACK on the direction: event enum (funder/fundee, peer adversarial modes, conf/reorg, disconnect/reconnect) is the right shape for a state-machine fuzzer.

Please clarify before a full ACK

1. Default CI / developer cost — Is the fuzz target skipped in plain go test ./funding (build tags, short mode, or fuzz-only entrypoints)? A ~3kLOC harness is worth it if day-to-day tests stay fast; please document the intended go test -fuzz=... -fuzztime= invocation in the PR body or funding package comment.
2. Failure oracle — Beyond panics, which invariants are checked (e.g. consistent chan IDs after confirm, no progress after fatal remote errors, funding tx / short chan id agreement across roles)? A short bullet list would help reviewers trust the harness.
3. Entropy — Confirm peer/crypto/timing inputs are derived from fuzz data (no unintended wall-clock flakiness except explicit timeout paths).
4. go.mod alignment — On a quick skim the new file imports look sensitive to btcd module paths; CI on this branch is the source of truth — green module build is enough.

Happy to re-review after the CI/skip + oracle notes land. Not requesting changes on concept — just wanting the operational story explicit for maintainers.