[PB-5865] fix(file-versioning): use updated tier data to apply version limits correctly

[douglas-xt]

What does this PR do?

Ensures that file version limits are correctly applied when users change their subscription plan.

Why are we doing this?

When users upgrade or downgrade their subscription, file versions should be adjusted according to their new plan limits. Previously, the version cleanup process was not executing reliably because it was using outdated plan information.

How are we doing this?

Instead of querying the user's plan information from the database after updating it, we now use the plan information that was just updated. This prevents reading stale data and ensures version limits are applied immediately and accurately.

Should this be manually tested & how?

This was tested locally by executing the complete end-to-end flow:

1. Registered a test user
2. Upgraded from Free to Ultimate plan by triggering Stripe webhook events using Stripe CLI from the payments gateway container
3. Created 30 file versions (correctly kept only 20 due to Ultimate plan limits)
4. Downgraded from Ultimate to Premium plan using Stripe CLI
5. Verified that only 10 versions remained (Premium plan limit)
6. Validated version cleanup executed correctly at each tier change

Any background context?

This fix addresses a production issue where file versioning cleanup had inverted behavior during plan changes. Plan limits determine version retention policies, and using fresh plan data ensures these policies are enforced correctly. This issue only occurs in production and is not reproducible in test environments. We suspect this is caused by a race condition, database caching, or reading from different database instances (replicas) when querying user plan information immediately after updating it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud