[Quality][Medium] Improve export streaming and quota enforcement: bounded performance and operational visibility #1537

Problem

The current export streaming and quota enforcement implementation is a production-quality risk area: Large exports must be bounded and streamed while enforcing organization quotas consistently across concurrent requests.

This issue requires meaningful implementation and focused tests. Typo-only, documentation-only, formatting-only, dependency-only, and cosmetic changes do not satisfy the scope.

Objective

bound rendering, polling, network, and memory costs while making degraded behavior observable for the implementation anchored at src/routes/exports.ts; src/routes/exports.quota.test.ts.

Scope

• Establish the feature's explicit state, data, authorization, and failure invariants.
• Set explicit bounds for pagination, polling, chart points, upload sizes, and concurrent requests where applicable.
• Avoid redundant fetches and state updates during route changes, reconnects, or rapid user interaction.
• Expose actionable client telemetry or structured diagnostics for latency, failure, and recovery paths without leaking secrets.
• Keep the change focused on this feature and preserve unrelated public behavior.

Acceptance criteria

• The implementation defines and enforces the relevant invariants for normal and adversarial inputs.
• Set explicit bounds for pagination, polling, chart points, upload sizes, and concurrent requests where applicable.
• Avoid redundant fetches and state updates during route changes, reconnects, or rapid user interaction.
• Expose actionable client telemetry or structured diagnostics for latency, failure, and recovery paths without leaking secrets.
• Automated tests cover success, failure, boundary, retry, and permission behavior applicable to this feature.
• The PR includes validation commands, design tradeoffs, and any remaining limitations.
• The PR references this issue using Refs #<issue-number>.

Priority

Medium — determined by the potential impact on correctness, user funds or data, security, availability, and implementation depth.

Non-goals

• Do not make typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes.
• Do not remove tests merely to make CI pass.
• Do not introduce secrets, credentials, unsafe network defaults, or unrelated refactors.

Contributor application

Before starting, comment with relevant experience, a concise implementation approach, the main risks or tradeoffs, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding.

Submission requirements

• Use PR title format: [#<issue-number>] <short summary>.
• Address every acceptance criterion in the PR description and implementation.
• Include focused automated tests and validation results.
• Explain any unavoidable limitations or pre-existing CI failures.
• Address maintainer review feedback before requesting final review.

Quality evaluation will consider scope adherence, implementation quality, test depth, security, correctness, review responsiveness, and follow-up stability.