feat: multi-campaign registry contract (milestonex-campaigns-registry)

[Sammygee12]

Summary

Issue #44 asks for a contract-level multi-campaign registry, since milestonex-campaign is single-campaign-per-instance by design. This adds a new, additive contract crate — campaigns-registry/ (milestonex-campaigns-registry) — implementing the API the issue's acceptance criteria describes:

• create_campaign(creator, metadata) -> u64
• donate(donor, campaign_id, amount, asset)
• end_campaign(campaign_id) / cancel_campaign(campaign_id) — creator-driven status transitions, plus automatic Active → GoalReached on donation
• get_campaign(campaign_id) / get_campaign_status(campaign_id) / campaign_count() — read views
• MAX_CAMPAIGNS_PER_INSTANCE constant (10,000), enforced in create_campaign
• All reads/writes scoped by campaign ID (DataKey::Campaign(id), DataKey::DonorData(id, donor))
• Typed Error enum whose discriminants numerically match milestonex-campaign::types::Error wherever the two contracts share a concept (see doc comment on campaigns-registry::types::Error)

This does not modify milestonex-campaign — the "Option B (conservative)" canonical-contract decision in the README is unchanged; campaign/ remains canonical for single-campaign deployments. campaigns-registry is a separate, additive contract for the many-campaigns-per-instance case campaign/ intentionally doesn't cover.

Full API, storage-scoping model, migration plan, and explicitly-deferred scope (milestones, refunds, multi-asset release, freeze/upgrade, reentrancy lock, diagnostics, real token custody — none of which are in issue #44's acceptance criteria) are written up in docs/multi-campaign.md.

On the "Issue 9 (type unification)" dependency

Issue #44 lists "Issue 9 (type unification)" as a dependency. I checked GitHub issue #9 in this repo — it's about donate's per-milestone read loop, not type unification, so that cross-reference doesn't currently resolve to a tracked issue here. Separately, I found that milestonex-common's CampaignStatus/AssetInfo types are already unused by campaign/ (it depends on common but never imports it) and have drifted from what campaign actually implements. campaigns-registry follows campaign's own practical approach (local types, no common dependency) rather than the aspirational shared crate. Both points are written up in docs/multi-campaign.md's "Type unification note" in case a type-unification issue needs to be filed separately.

This is a major feature — flagging for roadmap review

The issue itself asks to "coordinate with roadmap" given the scope. This PR is a complete, tested starting point for that review, not a claim that rollout details (whether this becomes the recommended path for new multi-campaign integrations, deployment plumbing, etc.) are already decided.

Closes #44

Test plan

• 12 tests across create_campaign_tests.rs, donate_tests.rs, status_transition_tests.rs, and concurrent_campaigns_tests.rs (the last directly covers the acceptance criteria's "5+ concurrent campaigns, distinct counters, distinct statuses" requirement), plus 3 error-table tests in types.rs mirroring campaign's own error-code test pattern.
• I could not run cargo check/cargo test/cargo fmt for this crate. This environment's MSVC linker fails building proc-macro2's build script (pre-existing, environment-level — same failure occurs on main before this PR's changes, e.g. building campaign itself hits the identical error). Every function in this PR was written by closely mirroring already-compiling code in campaign/src/*.rs (same storage/TTL patterns, same panic_with_error!/validate_campaign_transition idioms, same test fixture style via env.as_contract + env.register_contract), and I did a manual line-by-line review against those proven patterns, but this has not been compiler-verified. Please run cargo test -p milestonex-campaigns-registry in CI/a working toolchain before merge — I'd expect at most minor fixes needed, but I can't rule that out without a working build.

🤖 Generated with Claude Code

[P3az3]

LGTM