feat: block refunds for past orders (refunds_blocked_until)

[stilla]

Summary

Adds a more granular refund-blocking option alongside the existing refunds_blocked flag (PR #10029).

Instead of blocking ALL refunds for an org, this allows blocking refunds only for orders created up to the moment the button is clicked, leaving future orders refundable.

Changes

• Model: Added refunds_blocked_until nullable TIMESTAMP(timezone=True) column to Organization
• Migration: New Alembic migration to add the nullable column (no backfill needed)
• Backoffice endpoint: POST /{organization_id}/refunds-blocked-until?blocked=true|false — sets cutoff to now() or clears it
• Refund service: Blocks refunds for orders with created_at ≤ refunds_blocked_until
• Backoffice UI: New Danger Zone row "Block Past Order Refunds" in the organization settings section
• Tests: 3 new tests covering before-cutoff, after-cutoff, and null cutoff scenarios

How it works

When a backoffice operator clicks "Block Past Refunds", refunds_blocked_until is set to the current UTC time. Any refund attempt for an order whose created_at ≤ refunds_blocked_until is rejected with RefundsBlocked. Future orders remain refundable. Clicking "Clear Past Refund Block" resets the field to None.

_{Stilla Canvas. Ask @stilla for more context.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
polar	Ready	Preview, Comment	Mar 10, 2026 4:48pm
polar-sandbox	Ready	Preview, Comment	Mar 10, 2026 4:48pm

[github-actions]

OpenAPI Changes

No changes detected in the OpenAPI schema.

[github-actions]

⚠️ Migration Isolation Check Failed

This PR contains database migrations along with other code changes. To ensure safe deployments, please split this into separate PRs,
or verify that your changes will not break. Keep in mind that the API is deployed before the workers.

1. Migration PR: Only model changes and the migration file
2. Code PR: All other changes (can be merged after migration PR)

Files that should be in a separate PR:

• server/polar/backoffice/organizations_v2/endpoints.py
• server/polar/backoffice/organizations_v2/views/sections/settings_section.py
• server/polar/refund/service.py
• server/tests/refund/test_service.py

Why?

Migrations are deployed separately and run before code changes. Mixing them can cause deployment issues if the new code depends on the migration.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.