An agent flagged some blockers in publishing the live preview of the MR.
I want to go with the robust, structural server-side solution. If everything works, you can test it by moving a task to Doing. Read the comments first to check whether the task seems to be affected by this problem.
The other agent should resume from that point. Wait for that agent to complete successfully before confirming your own success.

This is the agent comment:

implementation done & pushed, but the MR preview URL itself is broken for all MRs (not just this one), which blocks the verification step in CLAUDE.md → Task workflow #5.

MR: https://gitlab.wikimedia.org/daanvr/upload-workbench/-/merge_requests/9
Preview path that should work: https://upload-workbench.toolforge.org/mr-9/

What I observed:

deploy:mr job succeeded; its log clearly shows VITE_BASE_PATH=/mr-9/ npm run build produced dist/assets/index-yNrmXvC7.js (note the hash) and rsynced it to /data/project/upload-workbench/www/static/mr-9/. The asset itself is reachable: curl /mr-9/assets/index-yNrmXvC7.js → 200, 351 KB, real bundle bytes.
But curl https://upload-workbench.toolforge.org/mr-9/ returns the live-root index.html (etag e505bd38…, content-length 510, referencing the old /assets/index-DlCXJMMf.js from the v0.4.0 root deploy), not /mr-9/index.html.
Same behavior at /mr-10/ (sibling MR from another subagent): identical etag, identical bytes.
Direct hits to /mr-9/index.html 301-redirect to /mr-9/index, which 301s to /mr-9, which 200s with the live root's index.html. Toolforge's static-file fronting (lighttpd or Envoy?) appears to strip .html and then fall back to the root when nothing matches.
Root cause is in the per-MR preview infrastructure released in v0.4.0 (!8), not in this MR. The build is correct; URL routing on Toolforge can't reach mr-<iid>/index.html through /mr-<iid>/.

Options I see:

Fix .gitlab-ci.yml's deploy:mr to also rsync index.html to mr-<iid>.html (so /mr-<iid> resolves to a real file before lighttpd's .html-stripping kicks in) — quick, but breaks relative /mr-<iid>/assets/... references unless we also rewrite them, which defeats the point.
Configure the Toolforge webservice to disable the .html URL rewriting (probably via a .lighttpd.conf or url-static.html setting in the tool's home).
Roll back / rework the per-MR-preview feature so previews are served from a separate Toolforge tool subdomain instead of a subdirectory.
Override CLAUDE.md's verification rule for this task and let me push to Reviewing on the strength of npm run build succeeding + the MR diff — and treat the preview rollout as a follow-up task.
I don't want to guess your call here. Per CLAUDE.md the implementer cannot push to Reviewing if the preview doesn't load, so T425827 is parked here until you say which way to go. Will resume the moment you move this back to Doing.