[Billing] Implement safe plan-change flow instead of creating overlapping subscriptions

Problem

The current product has Free, Pro Monthly, and Pro Annual plans, but there is no complete plan-change lifecycle.

The Settings UI currently has:

Switch to Annual (Save 33%)

for monthly users, but the pricing flow ultimately calls the normal subscription-creation path.

That risks creating a second subscription instead of changing the existing one.

Expected behavior

Free -> Pro:

• create a new subscription;
• complete checkout;
• activate Pro.

Monthly -> Annual:

• use an explicit change-plan flow;
• determine how the existing monthly subscription is handled;
• use Razorpay's supported subscription update/upgrade mechanism where applicable;
• keep local DB and provider state synchronized;
• do not create overlapping active subscriptions.

Annual -> Monthly:

• same principle;
• explicit change-plan action;
• no accidental duplicate subscription.

Cancellation should remain a separate action.

UX wording

Use:

• "Upgrade to Pro" for Free -> Pro.
• "Switch to Annual" for Monthly -> Annual.
• "Switch to Monthly" for Annual -> Monthly.
• "Change Plan" as the generic settings action.

Avoid presenting plan changes as ordinary new purchases.

Implementation requirements

Add a server action such as:

changeSubscriptionPlanAction(targetPlan)

which:

1. authenticates the user;
2. resolves the canonical active subscription;
3. validates the target plan;
4. checks whether target == current;
5. calls the provider-specific plan-change operation;
6. updates local state only after provider success;
7. records an audit event;
8. reconciles through webhook/provider retrieval.

Extend IBillingProvider only if Razorpay actually requires a provider operation for this.

Do not fake a plan change by simply editing the local plan field.

Acceptance criteria

• No normal UI flow creates two active paid subscriptions for one user.
• Provider and local subscription states remain consistent.
• Monthly -> Annual works or is explicitly blocked with a clear message if the provider flow is not yet ready.
• Annual -> Monthly behaves consistently.
• Tests cover both directions and failure/rollback cases.

Start by tracing the Settings pricing flow and its normal subscription-creation path, then inspect the server action boundary and IBillingProvider/Razorpay integration. Determine the provider-supported operation for both plan-change directions and how webhook or provider retrieval reconciles local state. Done means duplicate active subscriptions are prevented, failure cases are covered, and the stated acceptance scenarios pass.