sec: narrow CSRF exemption for approve/cancel POST endpoints (closes #404)

[cristim]

Summary

• Removes the blanket /api/purchases/approve/ and /api/purchases/cancel/ entries from requiresCSRFValidation's exemption list. These routes are already covered by isPublicEndpoint(), so the middleware never reached CSRF validation on the token-only path anyway -- but the exemption was leaving session-authenticated POSTs unprotected.
• Adds validateCSRF() calls at the entry of approvePurchaseViaSession and cancelPurchaseViaSession -- the two functions that mutate state under session authentication (issues feat(history): inline Cancel button for pending purchase rows #46/feat(api,history): add Approve button + approve-{any,own} RBAC for in-dashboard purchase approval #286 added these session branches). The token-only (email-link) path never calls these functions and is unaffected.
• Updates 6 existing tests to supply ValidateCSRFToken expectations on the session-authed branches they exercise, and updates one test whose expected error message changed (CSRF fires before requireSession, so tokenless requests now get 403 instead of 401).

Attack scenario closed

A logged-in user's browser could previously be CSRF-forged into approving or cancelling a purchase if the attacker knew the execution ID. The session branch added in issues #46/#286 bypassed CSRF because the blanket middleware exemption applied unconditionally. This fix closes that gap.

Test plan

• TestApproveViaSession_RequiresCSRF: session POST without CSRF token -> 403 "CSRF validation failed"
• TestApproveViaSession_PassesCSRF: session POST with valid CSRF token -> 200 "completed"
• TestCancelViaSession_RequiresCSRF: session POST without CSRF token -> 403 "CSRF validation failed"
• TestTokenOnlyApprove_BypassesCSRF: email-link token path never calls ValidateCSRFToken (no mock registered; unexpected call would panic)
• All 1359 existing internal/api tests pass
• go build ./... succeeds

Closes #404

[coderabbitai]

Warning

Review limit reached

@cristim, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 31 minutes and 1 second. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 58667d0d-df50-4d88-bbc4-70c0d6d802ba

📥 Commits

Reviewing files that changed from the base of the PR and between 4956d66 and 2964c87.

📒 Files selected for processing (5)

• internal/api/coverage_gaps_test.go
• internal/api/handler_purchases.go
• internal/api/handler_purchases_test.go
• internal/api/middleware.go
• internal/api/middleware_test.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/404-wave21

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.