feat(#563): Allow proportional withdrawals based on milestones

[Banx17]

Overview

This PR introduces proportional, milestone-based withdrawals for campaigns that enable uses_milestones, resolving #563.
Currently, funds can only be withdrawn if all milestones are verified. This PR updates the withdrawal logic to allow creators to withdraw funds progressively as individual milestones are verified.

Changes Made

• Added CampaignWithdrawnAmount(u32) to DataKey in src/storage.rs to safely track the gross amount processed for withdrawals without breaking existing Campaign data structures.
• Updated withdraw_funds in src/campaigns/withdraw.rs to allow partial withdrawals. The amount processed in each step is bounded by the total sum of target_amount across all verified milestones, capped at amount_raised.
• Calculated proportionate platform fees and reserve withholdings for each partial withdrawal step, correctly accumulating into CampaignReserve.
• Marked campaign.funds_withdrawn = true and campaign.is_active = false only once the entire raised amount is processed.
• Added comprehensive test coverage in src/tests/test_issues.rs (test_milestone_proportional_withdrawals_563).

Validation

[npm run lint ✅ completed (existing repo warnings only)
npm run typecheck ✅ passed
npm test -- src/config/tests/config.test.ts --runInBand ✅ passed (9/9)
npm run build ✅ passed]

Fixes #563

[drips-wave]

@Banx17 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

[davidmaronio]

this is the real milestone-withdrawals feature and the logic checks out, the new CampaignWithdrawnAmount key is additive (defaults 0 for existing campaigns, no orphaning), the reserve accumulation and partial to_process accounting look correct, and test passes. just ci: clippy fails on an unnecessary as u32 cast (u32->u32), remove it, and cargo fmt fails on a few files (update.rs:5 long import, withdraw.rs:109, storage.rs:949, the test files), run cargo fmt. fixing that cast also unblocks #580/#579 which sit on this branch. once green this is good to go.