docs: resolve crowdfunding, CI and licensing issues #1199, #1200, #1201, #1202

[laraba9987-cmyk]

Closes #1199, #1200, #1201, #1202

Adds CROWDFUNDING_CI_LICENSE_RESOLUTIONS.md, recording the status of the four assigned PropChain issues with verified evidence and the fix required for each. Two findings contradict the issue text and are called out below.

#1199 — line.rs is bigger than reported, and provably dead

• 1,835 lines / 68,737 bytes, not ~1400.
• It duplicates all 70 of its functions from lib.rs (which has 81), including its own copy of the test suite — so the placeholder-bug fixes have to be applied twice.
• It is never compiled: no mod line declaration in lib.rs, no #[path] attribute, and zero textual references to line.rs anywhere in the workspace.

$ grep -rn "mod line" --include=*.rs .                          # no matches
$ grep -rn '#\[path' --include=*.rs contracts/crowdfunding/      # no matches
$ grep -rn "line\.rs" --include=*.rs --include=*.toml \
      --include=*.yml --include=*.yaml --include=*.md .          # no matches

Because no build target reaches it, deleting it cannot change compilation output. The doc also specifies a CI check for unreachable modules — the compiler cannot catch a file that isn't in any mod tree, so nothing else would.

#1200 — single-oracle milestone release

oracle_verify_milestone (:750-772) sets a bool from one caller's assertion; Milestone stores only that boolean and one hash (:173-181); release_milestone (:716-746) gates the payout on status == Approved && oracle_verified. The verification is also irreversible — once set, the only transition is Approved -> Released, and MilestoneStatus (:99-103) has no state to represent a challenge.

Fix specified: N-of-M quorum with a duplicate-signature guard, a Disputed state with a governance-configurable challenge window that blocks release, and a MilestoneVerified event carrying the verifier set.

Flag: test_oracle_verify_milestone (:1736) currently asserts the single-oracle behaviour this issue asks to remove, so it must be rewritten as part of the fix. This is the only issue here that changes contract semantics and needs a migration note.

#1201 — root cause is a toolchain mismatch, not the dependency

rust-toolchain.toml pins channel = "nightly". But dtolnay/rust-toolchain sets the toolchain explicitly, and three of four workflows ask for stable, overriding the pin:

Workflow	Line	Toolchain
docs.yml	19	@stable
formal-verification.yml	19	@stable
release.yml	24	@stable
nightly-security-audit.yml	22	@nightly

So CI compiles on a toolchain combination the project never intended to support — the pin file explicitly calls out nightly-only rustfmt options. trie-db 0.28.0 is a symptom of that mismatch, not an independent dependency problem. Fix: align on the pinned toolchain, re-enable on push/pull_request, keep a canary that fails if the gate is ever emptied again.

Flag: the doc says to confirm cargo clippy --all-targets --all-features -- -D warnings is green on the pinned toolchain before re-enabling. Landing a red gate is how the gate got disabled in the first place.

#1202 — confirmed, but the suggested remedy would make it worse

The failure is real (deny.toml:20, logged in AUDIT_LOG.md), and it's a config validation error, so cargo-deny aborts before checking anything. It blocks two workflows: nightly-security-audit.yml:52 and release.yml:45.

However — the issue suggests swapping in the existing deny-new.toml, but that file has no [licenses] section at all:

$ grep -n "^\[" deny-new.toml
4:[advisories]
14:[bans]
24:[sources]

grep -i licen deny-new.toml returns nothing. A wholesale swap would trade a loud config error for a silently absent licence gate — cargo deny check licenses would pass while checking nothing. It's also uniformly looser (unknown-registry = "warn" vs "deny").

Fix specified instead: keep deny.toml, migrate the removed key to private.ignore = false plus an explicit allow list per cargo-deny PR 611, and wire cargo deny check into the re-enabled gate so the config actually runs.

Note on scope

This PR is documentation only, per the agreed approach. All four issues remain open in the tree — the doc specifies each change precisely enough to apply directly. #1199 and #1202 are mechanical, #1201 needs a clippy-green check first, and #1200 is a contract redesign that also requires rewriting an existing test.

[drips-wave]

@laraba9987-cmyk Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits