feat: use plan change estimation in billing flow

[HarshMN2345]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR lifts the plan-change estimation call out of EstimatedTotalBox and into the parent change-plan page, sharing a single estimationUpdatePlan response between the billing box and the new per-project compliance table in OrganizationUsageLimits.

• Centralised estimation: loadPlanChangeEstimate in the page drives both EstimatedTotalBox (via estimationOverride/preferExternalEstimate) and OrganizationUsageLimits (via planChangeEstimate/loading/estimateError), with a request-ID mechanism to discard stale responses.
• Compliance table: organizationUsageLimits.svelte gains a new per-project breakdown table derived from planChangeEstimate.limits, plus success/warning/loading/error alerts; the legacy Free-plan limit table is now gated behind isDowngradingToFree.
• Bug fix: The pre-existing excessUsage.projects calculation was always returning the full project count instead of the excess above the limit; this is corrected to currentUsage.projects - freePlanLimits.projects.

Confidence Score: 3/5

Safe to merge after fixing the stale compliance display — no data loss risk, but users switching between downgrade targets see compliance alerts for the wrong plan while the real check is in flight.

The planChangeEstimate variable is never cleared at the start of loadPlanChangeEstimate, so compliance alerts in OrganizationUsageLimits keep showing the previous plan's data while the new estimate loads. The loading indicator never appears during plan switches because targetPlanLimits remains truthy with stale data.

src/routes/(console)/organization-[organization]/change-plan/+page.svelte — loadPlanChangeEstimate should reset planChangeEstimate to null before each new request.

Important Files Changed

Filename	Overview
src/routes/(console)/organization-[organization]/change-plan/+page.svelte	Introduces plan-change estimation with request-ID deduplication and reactive guards; planChangeEstimate is not cleared at the start of each new request, causing stale compliance data to be displayed in OrganizationUsageLimits when the user switches between downgrade targets.
src/lib/components/billing/estimatedTotalBox.svelte	Adds estimationOverride and preferExternalEstimate props; normalizeItems handles both array and object-map API shapes; getEstimateDetails unwraps the nested estimation object correctly.
src/lib/components/organizationUsageLimits.svelte	Adds per-project compliance table driven by planChangeEstimate; the loading/error/success alerts are gated correctly; fixes the longstanding excessUsage.projects off-by-one bug.

_{Reviews (4): Last reviewed commit: "fix: block unsafe downgrades on estimate..." | Re-trigger Greptile}

[greptile-apps]

When the user switches between downgrade targets, planChangeEstimate is never cleared before the new request fires. Because targetPlanLimits in OrganizationUsageLimits is derived from planChangeEstimate, the compliance alerts continue to show the previously selected plan's data while the new request is in flight. The {:else if loading} "Checking plan limits" indicator only renders when targetPlanLimits is null — but since the old value is still there, that indicator is never shown during plan switches, only during the very first load. Users changing plans see compliance alerts for the wrong plan while the real check is running.

Suggested change

	isLoadingPlanEstimate = true;
	planEstimateError = null;
	try {
	isLoadingPlanEstimate = true;
	planEstimateError = null;
	planChangeEstimate = null;
	try {