Add package age policy and upload size limit configuration UIs

[brandonrc]

Summary

Adds two repository configuration surfaces for v1.2.0.

Package age policy (#265) — a "Package Age Policy" section on the repo Settings tab. When enabled, freshly published packages pulled through a remote repository are held in quarantine for a configurable cooldown window (hours or days). This gives time to flag a compromised upstream release before it reaches clients, mitigating supply-chain attacks. The toggle and duration are written to PATCH /api/v1/repositories/{key} as quarantine_enabled and quarantine_duration_minutes (the per-repo keys the backend stores in repository_config, per artifact-keeper/artifact-keeper#709). These fields are not in the generated SDK yet, so the call goes through apiFetch, matching the existing pattern for upstream-auth and test-upstream.

Upload size limit (#189) — the admin Settings -> Storage tab previously showed Max Upload Size read-only. It is now editable (numeric value + MB/GB unit selector + Save), persisted via POST /api/v1/admin/settings. Because that endpoint replaces the whole SystemSettings object, the save reads current settings first and sends them back with only max_upload_size_bytes changed, so sibling values are preserved. The repo Settings tab also surfaces the effective limit read-only so repo owners can see the instance-wide ceiling that applies to uploads.

Test Checklist

• Unit tests added/updated
• E2E Playwright tests added/updated
• Manually tested locally
• No regressions in existing tests

UI Changes

• Playwright E2E spec covers the change
• Responsive layout verified (mobile + desktop)
• Dark mode verified
• Accessibility checked (keyboard navigation, screen reader)
• N/A - no UI changes

Closes #265
Closes #189

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[brandonrc]

Accessibility review (WCAG 2.2 AA) of the age-policy and upload-size forms. NOTE: this contains an a11y BLOCKER (would be a request-changes; posting as a comment because GitHub does not allow request-changes on one's own PR). Please treat item under "Blocker" as merge-gating.

Positive findings

• Age policy: <section aria-labelledby="settings-age-heading"> tied to a real <h3 id>. The enable Switch has <Label htmlFor="settings-age-enabled">; the cooldown <Input id="settings-age-duration"> has <Label htmlFor>. Toggle-gated disabling (disabled={!ageEnabled}) is correct and conveyed natively (1.3.1, 4.1.2, 3.3.2).
• Upload size (global Settings): <Label htmlFor="max-upload-size">, the unit SelectTrigger has aria-label="Upload size unit", Save disabled until dirty. The read-only mirror on the repo settings tab uses disabled + aria-label="Upload size limit". Good.

Blocker (Serious, WCAG 3.3.1 Error Identification / 4.1.3 Status Messages)
The cooldown validation error in repo-settings-tab.tsx is not programmatically associated with the input. The input sets aria-invalid={ageInvalid}, but the error paragraph:

{ageInvalid ? (
  <p className="text-sm text-destructive">Enter a cooldown period of at least one ...</p>
) : ( ... )}

has no id, no role="alert", and #settings-age-duration has no aria-describedby pointing at it. A screen-reader user who clears the field hears only "invalid" with no reason, and the new error text is never announced. Fix:

• give the error <p> a stable id (e.g. settings-age-duration-error) and role="alert";
• set aria-describedby={ageInvalid ? "settings-age-duration-error" : undefined} on the cooldown <Input>.

Reuse the exact pattern PR #459 established for the create-dialog key error (create-key-error + role=alert + aria-describedby).

Non-blocking

• Minor: the helper/error <p> swaps between description and error text in the same slot. With role="alert" only on the error variant, this is fine; ensure the description variant does NOT carry role="alert" (it currently does not).
• Minor (4.1.3): upload-size Save success/failure is toast-only. Acceptable for an admin action.

Once the cooldown error is associated via aria-describedby + role="alert", this is good to go. Not approving/merging.

[brandonrc]

Test/E2E quality review (v1.2.0 batch). Verdict: the unit helpers are well-covered; the e2e UI tests are soft (best-effort POST checks that pass even when nothing is saved).

Unit tests (#189) — solid. bytesToUploadSize/uploadSizeToBytes cover whole-GB, MB fallback, 0-as-no-limit (empty value), reverse conversion, invalid input ("", -1, abc => 0), and a round-trip. The "0 bytes = no limit / empty input" cases are exactly the edge conditions the feature hinges on, and they're real assertions. The page.test.tsx updates correctly switch from asserting "1 GB" text to asserting a spinbutton with value "1", matching the new editable control. Good.

upload-size API e2e — good. admin settings expose and accept a new max upload size does GET, asserts max_upload_size_bytes present, POSTs a changed value, GETs again and asserts after.max_upload_size_bytes === target. Read-after-write is a genuine round-trip assertion, with idempotent restore. No skip.

The soft spots — saving a changed upload size issues a settings POST and the age-policy save test. Both use the pattern:

const postResponse = page.waitForResponse(...).catch(() => null);
await save();
const posted = await postResponse;
if (posted) { expect(posted.status()).toBeLessThan(400); }

If the POST never fires (button mis-wired, validation silently blocks, the row's Save targets the wrong mutation), waitForResponse times out, .catch yields null, the if (posted) block is skipped, and the test passes green. That is an assertion that cannot fail on the exact regression it purports to guard. The body !== 'Application error' check is too weak to compensate. To actually prove the save: drop the .catch(()=>null)/if and assert the POST fires AND its body contains the changed value, or assert read-after-write through the UI. As written, the "issues a settings POST" test does not reliably prove a POST is issued.

age-policy — mixed. The API tests are real (PATCH stores policy => ok; negative cooldown -10 => >=400, a genuine negative case). The UI test has good intent (cooldown disabled until toggle enabled, then toBeEnabled after click) and those ARE distinguishing assertions, but the final save reuses the same conditional if (saved) pattern, so the save outcome itself isn't guaranteed asserted. Tighten the save assertions; the disabled/enabled toggle and API tests are fine. Not requesting changes, but the conditional-POST pattern should be fixed before treating these as save-flow coverage.

[brandonrc]

Frontend/React correctness review. One real correctness bug (stale initial state); treat it as a blocker even though this is posted as a comment (the review tool won't let me request-changes on my own PR).

Blocker: UploadSizeSetting shows the wrong current value after load

src/app/(app)/(admin)/settings/page.tsx

const initial = bytesToUploadSize(currentBytes ?? 0);
const [value, setValue] = useState(initial.value);
const [unit, setUnit] = useState<UploadSizeUnit>(initial.unit);

The parent SettingsPage renders the Storage tab (and therefore this component) unconditionally; it does not gate the whole tab on settingsLoading (only individual SettingRow values via storageValue). So UploadSizeSetting mounts while currentBytes is still undefined, useState captures value = "", and useState never re-runs when the query resolves. Result: once loading finishes, the editable input shows an empty field ("No limit" placeholder) even when a real limit is configured, misrepresenting the persisted value. Save is disabled until dirty, so it won't silently zero the limit, but the displayed state is wrong.

Fix options:

• Render the editor only once data is present (return the loading row until currentBytes != null, then mount the editor so its initial state is correct), or
• Add a key={currentBytes} to remount on value change, or
• Sync with the "adjust state during render" pattern (track last-seen currentBytes in state and reset value/unit when it changes), guarding against clobbering in-progress edits.

A unit/RTL test that mounts with loading=true then flips to loading=false with a non-zero currentBytes would have caught this.

Suggestions

• Age policy form is write-only with fixed defaults. ageEnabled/ageValue/ageUnit default to false/"3"/"days" and are never seeded from the repo's stored quarantine_enabled/quarantine_duration_minutes. A repo already quarantining at 7 days will display "disabled / 3 days", and saving overwrites the real config. This is the same write-through tradeoff as #462's release target; if there's no GET to read current state, at least say so in the UI (e.g. "current value not shown") so an admin doesn't assume the form reflects what's stored.
• settingsApi.updateMaxUploadSize does a read-modify-write that spreads the entire getSettings() response back into the POST. This is the documented approach for the replace-whole-object endpoint, but it (a) has a TOCTOU window if two admins save concurrently and (b) round-trips any read-only/computed fields the GET returns. Acceptable given the endpoint shape; worth a comment that the GET and POST schemas are assumed identical.

The apiFetch usage and bytesToUploadSize/uploadSizeToBytes/ageToMinutes helpers are clean and well unit-tested.

Merge sequencing (not a defect)

Overlaps #462 on repo-settings-tab.tsx and #463/others on settings/page.tsx. Known, will be merge-sequenced.

[brandonrc]

Shipped in v1.2.0. The changes from this PR were folded into the release integration branch #466, which was squash-merged to main and tagged as v1.2.0. The code is already on main, so closing this as superseded by #466 rather than merging it (re-applying would just duplicate what already shipped). No work lost. See #466 for the consolidated record.