[PB-6684]: allow partners to define a hard storage quota for sub-accounts

[victor-ferro]

What

Partners can now set a maximum storage quota on a sub-account and remove it again. The sub-account detail view gets a "Storage Quota" card showing the current limit and the storage in use, with a field to set a new limit in TB and a link to remove it. The sub-accounts table gets a "Storage Quota" column showing usage against the limit as a bar, amber at 80% and red at 100%. Sub-accounts with no limit read "No limit" in both places.

Why

PB-6684. Partners need a hard cap per sub-account so a single customer cannot consume storage without limit. The limit is enforced by Wasabi, since the browser uploads straight to S3 and our backend never sees the traffic, so this is the control surface: it configures the limit and reports it back.

Related to https://github.com/internxt/object-storage-server/pull/97

Notes

• The UI has no approved design yet. Layout, copy and colours are a proposal.

• The table column was not asked for by the ticket. It was added because the information sits naturally next to the storage figures, and previous PRs already extended this table. Happy to drop it.

• Usage is assessed every 24 hours by Wasabi, so a limit does not take effect the moment it is saved, and nothing in the UI says so. A line explaining it was drafted and then removed because the ticket does not ask for it. Raising it here for the team to decide whether it should go in.

• Tailwind's default palette does not exist in this project. @internxt/css-config replaces it, so classes like bg-indigo-600 or text-gray-400 generate no CSS and this screen renders almost entirely black on white. The new buttons follow the same style as their neighbours, so that if this is not intentional they get fixed whenever the rest is.

• The detail view is shared by the management and partners consoles, but lives in src/management/. Whether the quota card renders is decided by optional methods on the injected service: partners injects a service that exposes them, management does not. That is a workaround rather than access control — what actually stops management from setting quotas is that the backend does not expose these endpoints under /management/*. Moving the shared code out of management/ into a neutral folder is probably better as a separate ticket, but it could be done here if the team prefers. It is also why two files in this PR sit under src/management/ while the scope is partners.

• No tests: this repository has none and no runner. Verified manually, and npm run build passes.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	object-storage-management-web	97cdfaf	Commit Preview URL Branch Preview URL	Aug 07 2026, 06:37 PM

[cloudflare-workers-and-pages]

Deploying object-storage-web with    Cloudflare Pages

Latest commit:	97cdfaf
Status:	✅  Deploy successful!
Preview URL:	https://51f8a5bb.object-storage-web.pages.dev
Branch Preview URL:	https://pb-6684-hard-storage-quota.object-storage-web.pages.dev

View logs