test(e2e): verify remote-repo cached artifacts show in the browser

[brandonrc]

Summary

Fixes the v1.2.0 regression reported in #424: when using remote (proxy) repositories, artifacts pulled through stopped appearing in the repo browser. Storage filled up (bytes were written) but the UI listed 0 artifacts, so users could not browse or scan them.

Root cause is in the backend. #1278 / #1280 stopped recording proxy-cached items in the artifacts table to fix a filesystem doubled-prefix storage path bug. The acknowledged tradeoff was that remote-cached items no longer surfaced in GET /api/v1/repositories/{key}/artifacts, which is exactly what the repo browser lists from. The backend fix (artifact-keeper#1567, tracking artifact-keeper#1548) reconstructs the listing for remote repos from the proxy cache, preserving the #1278 fix.

The web client already consumes the corrected data through the same endpoint, so no web code change is required. This PR adds the Playwright regression test for the user-visible flow:

• Pulls a small package (is-odd) through the seeded e2e-npm-remote proxy.
• Asserts the cached entry appears in the listing API with real size and checksum.
• Asserts the entry shows as a row in the Artifacts tab of the repo detail page.

The spec skips gracefully if the upstream registry is unavailable (upstream availability is not what's under test). It runs in CI against the 1.2.0 backend image.

Test Checklist

• Unit tests added/updated
• E2E Playwright tests added/updated
• Manually tested locally — eslint and tsc pass on the new spec
• No regressions in existing tests

UI Changes

• Playwright E2E spec covers the change
• N/A - no UI changes

This is a test-only change; the behavior fix lands in the backend (artifact-keeper#1567).

Closes #424

[github-actions]

Dependency Review

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

Scanned Files

None

[brandonrc]

Test/E2E quality review (v1.2.0 batch). Verdict: the assertions ARE good when they run, but both tests sit behind an upstream-availability skip that will frequently swallow the whole fix in CI. This is the one I am most skeptical of.

The skip problem. Both tests call pullThroughProxy() and, if !resp.ok(), do test.skip(true, 'Upstream NPM registry unavailable...'). The bug under test (#424: remote-cached items vanished from the listing) can ONLY manifest after a successful pull-through. So whenever registry.npmjs.org is unreachable, slow, or rate-limited from the CI runner, both tests go green having asserted nothing about the fix. For a release-gate e2e that depends on a third-party registry, this is a real "perpetually green without testing" risk, not a theoretical one. The comment frames upstream availability as out of scope, but the practical effect is that the fix's only e2e coverage is conditional on a flaky external dependency.

When it does run, the assertions are honest. The listing-API test asserts items.length > 0 (the regression was an empty listing), finds the package by path/name, and asserts size_bytes > 0 and checksum_sha256 truthy, proving the reconstructed-from-sidecar metadata is real, not stubbed. The UI test asserts a row containing the package is visible in the Artifacts tab. These genuinely distinguish fixed-vs-broken.

Recommendation. Reduce the external dependency: either (a) seed the proxy cache deterministically (PUT a sidecar+content pair into proxy-cache/<key>/... via storage, or a fixture upstream served by the test harness) so the listing assertion always runs, or (b) point the remote at a local stub registry. Pair this with the backend gap I flagged on #1567 (no unit test exercises list_cached_artifacts against a storage backend) — right now, between the two PRs, there is a plausible CI run where the entire #424 fix is asserted by nothing. Strongly suggest fixing the determinism before relying on this as release-gate coverage. Not formally requesting changes, but this is the weakest spec in the batch.

[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.