🎨 Palette: 파일 용량 초과 에러 메시지 개선

[seonghobae]

💡 What: 업로드 파일 용량 초과 시 하드코딩된 '5 GiB' 에러 메시지를 제거하고, MAX_UPLOAD_BYTES 상수를 기반으로 동적으로 계산된 용량을 표시하도록 변경했습니다. 일괄 업로드 폼(batch input)의 경우 총 파일 크기가 백엔드 제한 용량을 초과하는지 여부도 함께 검증하여 사전에 오류를 방지합니다.

🎯 Why: 백엔드 제한값이 변경되더라도 클라이언트 측 에러 메시지에 변경 사항이 자동으로 반영되어 사용자에게 잘못된 정보를 제공하는 문제를 막고 혼란을 최소화하기 위함입니다. 일괄 업로드 시에도 사용자가 용량 초과 오류를 서버에 제출하기 전에 미리 알 수 있도록 하여 불필요한 대기 시간을 줄였습니다.

📸 Before/After: 파일 제한 용량이 하드코딩된 '5 GiB'에서 MAX_UPLOAD_BYTES 값을 동적으로 변환한 값(예: 5.00 GiB)으로 표시되며, 일괄 업로드 시에도 총 파일 크기 초과 여부가 올바르게 표출됩니다.

♿ Accessibility: setCustomValidity 및 aria-invalid 상태 변경과 더불어 aria-live 영역에 즉각적으로 초과된 용량 에러 메시지를 주입함으로써 화면 낭독기(Screen Reader) 사용자도 용량 초과 여부를 즉시 인지할 수 있도록 접근성을 개선했습니다.

---

PR created automatically by Jules for task 1669556879496276780 started by @seonghobae

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 66b7d8f1-4842-4ba7-999a-6474ea99b4f3

📥 Commits

Reviewing files that changed from the base of the PR and between 963291f and ad969a2.

📒 Files selected for processing (5)

• .jules/palette.md
• CHANGELOG.md
• pr_description.txt
• saas_web.py
• tests/test_saas_web.py

---

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Closing in favor of the narrower #365, and because this branch introduces a client/server contract mismatch.

The backend enforces MAX_UPLOAD_BYTES independently for each uploaded file in the batch loop; it does not enforce one aggregate batch-byte ceiling equal to the single-file ceiling. This PR makes the browser reject a batch whenever the sum exceeds MAX_UPLOAD_BYTES, so several individually valid files can be blocked even though the server accepts them. Client validation must not invent a stricter limit without a separately designed and enforced aggregate server contract, capacity model, error response, documentation, and tests.

The valid part—deriving the single-file message from the active constant—is isolated in #365. That maintained slice still needs behavior-level validation and removal of bot-journal metadata, but it does not add the unsupported aggregate restriction. No check or review from this branch transfers.

[google-labs-jules]

Closing in favor of the narrower #365, and because this branch introduces a client/server contract mismatch.

The backend enforces MAX_UPLOAD_BYTES independently for each uploaded file in the batch loop; it does not enforce one aggregate batch-byte ceiling equal to the single-file ceiling. This PR makes the browser reject a batch whenever the sum exceeds MAX_UPLOAD_BYTES, so several individually valid files can be blocked even though the server accepts them. Client validation must not invent a stricter limit without a separately designed and enforced aggregate server contract, capacity model, error response, documentation, and tests.

The valid part—deriving the single-file message from the active constant—is isolated in #365. That maintained slice still needs behavior-level validation and removal of bot-journal metadata, but it does not add the unsupported aggregate restriction. No check or review from this branch transfers.

Understood. Acknowledging that this PR introduces a client/server contract mismatch regarding the batch upload limit and is closed in favor of #365. I am stopping work on this task.