[BR-2181]:fix/show toast instead of storage-full dialog on rate-limited uploads

[jaaaaavier]

Description

The purpose of this PR is to fix a bug where a user would receive a 420 error (too many requests) when uploading a file, and the app would display ReachedPlanLimitDialog, when in reality the user had plenty of available space.

In UploadManager.ts, any error with status === 420 was always treated as "out of space" by directly invoking maxSpaceOccupiedCallback. However, the 420 status code is also used for rate limiting (e.g., when a user is backing up data with the desktop app while simultaneously uploading via the web), so the dialog was triggered incorrectly.

Fix
In uploadItemsThunk.ts, notifyMaxSpaceOccupied is added, replacing the previous callback in uploadItemsThunk and uploadItemsParallelThunk. Before deciding whether to open the dialog, it checks the plan's actual usage against its limit using planSelectors.planLimitToShow / planUsageToShow:

If the user truly has no space left (planUsage >= planLimit), the current behavior is kept and ReachedPlanLimitDialog is opened.
If the user does have available space, the dialog is not opened. The error still flows through the existing generic error handling in the thunk, which already shows a toast with the server's error message — so the user isn't left without feedback, they just no longer see the incorrect "storage is full" message.
Incidentally, isUploadAllowed (the pre-upload check) has been refactored to use the same selectors instead of duplicating the manual planLimit/planUsage calculation per workspace.

Two tests were added to uploadItemsThunk.test.ts covering both branches: the dialog is not opened when the account still has available space, and it is opened when the account has actually run out of storage.

Related Issues

Related Pull Requests

Checklist

• Changes have been tested locally.
• Unit tests have been written or updated as necessary.
• The code adheres to the repository's coding standards.
• Relevant documentation has been added or updated.
• No new warnings or errors have been introduced.
• SonarCloud issues have been reviewed and addressed.
• QA Passed

Testing Process

1. Run de app on local
2. Temporarily forced a 420 (status: 420) directly at the network entry point used by the worker (uploadFile in src/app/network/upload.ts), which is the exact call path that UploadManager.ts reacts to (handleUploadErrors → maxSpaceOccupiedCallback).
3. Reloaded the app and uploaded a real file, confirming:
   • With available storage: ReachedPlanLimitDialog is not opened; the upload error still surfaces through the existing generic error toast.
   • Caught and fixed an unrelated duplicate-notification issue this exposed (a second, redundant toast was being shown for the same error through the generic error-handling loop).

Additional Notes

[cloudflare-workers-and-pages]

Deploying drive-web with    Cloudflare Pages

Latest commit:	c518815
Status:	✅  Deploy successful!
Preview URL:	https://08f16305.drive-web.pages.dev
Branch Preview URL:	https://fix-false-storage-full-notif.drive-web.pages.dev

View logs

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud