feat: return 422 for invalid withdrawal destination_key (closes #391)

[collinsezedike]

What I built

withdrawals.js already validated destination_key with Keypair.fromPublicKey via the shared withdrawalValidation middleware, but the shared validateRequest handler only mapped validation failures to 422 for paths containing /contributions — everything else, including /withdrawals, fell through to 400. That meant an invalid Stellar key was rejected, just with the wrong status code, failing the issue's acceptance criteria.

Fixed validateRequest in backend/src/middleware/validation.js to also return 422 for /withdrawals paths, and added a regression test asserting an invalid destination_key on POST /api/withdrawals/request returns 422 with a clear error message.

Decisions worth noting

No new validation logic was added — the Keypair.fromPublicKey check already existed and matches the pattern used in contributions.js. This PR only corrects the status code mapping so the existing validation actually satisfies the issue's acceptance criteria.

How to test manually

1. POST /api/withdrawals/request with a valid campaign_id/amount and destination_key: "not-a-valid-key" → expect 422 with error.message containing "destination_key must be a valid Stellar public key"
2. Same request with a valid G-address destination_key → expect the normal 201 pending-request flow, unaffected

Checklist

• Acceptance criteria satisfied (422 on invalid key, clear message, valid keys unaffected)
• npm test — could not run in this environment (no node_modules installed); please run cd backend && npm test in review
• No files added beyond what the issue required
• PR is against main, branch is rebased and clean

Closes #391

[drips-wave]

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

[collinsezedike]

CI failures here (husky: not found in backend-checks, npm audit react-router advisory in frontend-checks) are pre-existing on main as well and unrelated to this change — confirmed by checking main's latest check runs.