ci(docker): publish a ps5upload-engine-webui image alongside the plain engine

[Twice6804]

Description

The webui Cargo feature and engine/Dockerfile.webui (merged in #171,
extended in #186) had no CI publish path. docker-engine.yml only ever
builds engine/Dockerfile, so ghcr.io/phantomptr/ps5upload-engine
never gains the browser web UI no matter how many version tags ship it
in the source tree — someone has to build Dockerfile.webui by hand
today to get an image with it.

This adds a second published image, ghcr.io/phantomptr/ps5upload-engine-webui,
built from Dockerfile.webui, published in lockstep with the plain
engine image on every release tag.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Code refactoring
• CI/build pipeline change

Changes Made

• .github/workflows/docker-engine.yml:
  • New verify-webui job — PR-time build-only smoke check of Dockerfile.webui (root context), mirroring the existing verify job for the plain engine.
  • resolve job now also derives image_webui = ghcr.io/<owner>/ps5upload-engine-webui.
  • New build-webui job — per-arch (amd64+arm64) digest build/push of Dockerfile.webui, mirroring build. Uses a distinct webui-digests- artifact prefix (not just a webui- infix) so the plain engine's merge job — whose pattern: digests-* glob only matches names starting with digests- — can't accidentally fold a webui digest into the minimal image's manifest. Uses a separate buildx cache scope (webui-<platform>) so the two Dockerfiles don't thrash each other's layer cache.
  • New merge-webui job — merges the webui per-arch digests into a multi-arch manifest tagged <version>, <major.minor>, and latest, same scheme as the plain engine.
  • PR trigger paths widened to include client/** (previously only engine/**), since the webui image's build depends on the frontend, not just the engine crate — a client-only PR can break Dockerfile.webui's build without touching engine/.
  • Both images still publish together from a single v* tag push or workflow_dispatch — one release cuts both.

Documentation Updates

Did you update the documentation? [ ] Yes [x] No

If no documentation updates: this is a CI/publish-pipeline change only — no user-facing behavior changes until the next version tag actually publishes the new image. The self-hosted README section documenting ghcr.io/phantomptr/ps5upload-engine-webui usage is still planned as a follow-up alongside capability gating (per #171/#186's "Additional Notes").

Testing

• npm run validate
• npm run coverage
• Built PS5 payload successfully
• Cross-platform CI target checks passed
• Tested on real PS5 hardware
• Tested desktop app
• Verified all example commands in docs work — validated the workflow YAML with python3 -c "import yaml; yaml.safe_load(...)" and with actionlint (downloaded the v1.7.12 release binary locally, since it's not preinstalled here); both clean, including a clean baseline run across all three existing workflow files.
• Tested edge cases and error handling — traced through the artifact-name collision risk explicitly: confirmed webui-digests-<platform> does not match the existing merge job's pattern: digests-* glob (which only matches names starting with digests-), so the two merge jobs can't cross-contaminate each other's manifest.

Not tested: an actual live run of this workflow (that requires a real tag push / workflow_dispatch on the upstream repo with GHCR push permissions, which I can't do from here). The structure is a mechanical mirror of the existing, already-proven verify/build/merge jobs — same actions, same steps, only context/file/image/artifact-name/cache-scope differ.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation to reflect my changes
• My changes generate no new warnings
• I have tested my changes on PS5 hardware (or simulated environment)
• All example code in documentation has been tested and works

Additional Notes

Once this merges, the webui image will start publishing from the next version tag pushed — it won't retroactively backfill :latest (or any other tag) from past releases. If you want an image available sooner than the next natural release, gh workflow run docker-engine.yml -f tag=<existing-tag> can re-run publishing for an already-tagged version once this workflow change is on main.

🤖 Generated with Claude Code