feat(webui): serve the full React client from the engine over HTTP

[Twice6804]

Description

Phase 1 of browser-accessible ps5upload (#151): the engine can now serve
the complete React frontend directly over HTTP, so a NAS/Docker user can
manage their PS5 from any browser without the native Tauri client.

This phase requires zero new engine routes — it reuses the existing
HTTP proxy endpoints the Tauri commands already call.

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

Changes Made

• client/src/state/engine.ts: in a browser (non-Tauri) context, the engine URL resolves to window.location.origin so every fetch call is same-origin.
• client/src/lib/browserInvoke.ts (new): translates invoke(cmd, args) calls into fetch() requests against the engine's existing HTTP routes; unsupported (native-only) commands throw a typed BrowserUnsupportedError.
• client/src/lib/invokeLogged.ts: branches on isTauriEnv() to route through browserInvoke instead of Tauri IPC when running in a plain browser.
• Redirected ~14 modules that imported invoke directly from @tauri-apps/api/core to go through invokeLogged instead, so they pick up the browser shim.
• engine/crates/ps5upload-engine: new webui Cargo feature (opt-in, default off) that embeds the built Vite dist/ via rust-embed and serves it with an SPA deep-link fallback (Router::fallback). Default (non-webui) builds are unchanged.
• engine/Dockerfile.webui (new): multi-stage build — Node stage builds the React client, Rust stage compiles the engine with --features webui and embeds the dist/ output, final FROM scratch stage matches the existing minimal image.

Documentation Updates

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

If no documentation updates: this is Phase 1 of a multi-phase rollout; the self-hosted README section documenting Dockerfile.webui and the PS5UPLOAD_ALLOW_IP requirement is planned for a follow-up PR once Phase 2 (remaining PS5-side screens) lands, so the docs describe the complete browser experience in one place rather than in installments.

Testing

• npm run validate equivalent: ran typecheck, lint, and the full Vitest suite (72 files / 754 tests) individually — all green.
• 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 — built and ran engine/Dockerfile.webui via Docker (local rustc is too old for direct cargo build), confirmed GET / serves the SPA, a client-side deep link (/library) correctly falls back to index.html, hashed assets serve with correct MIME types, and /api/version is unaffected.
• Tested edge cases and error handling — confirmed the webui feature is fully opt-in (default build unaffected) and that the SPA fallback doesn't shadow existing /api/* routes.

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

This is Phase 1 of a larger plan (frontend transport shim + static serving only). Phase 2 will add thin engine routes for the remaining PS5-side screens (Saves, Screenshots, Processes, Power, user list, SMP) that currently call ps5upload-core in-process from the Tauri shell, plus capability gating to hide native-only affordances (host file pickers, local FS browse, payload send from a local file) when running in a browser. Access control for the browser UI reuses the existing PS5UPLOAD_ALLOW_IP allowlist — no new auth was introduced.

🤖 Generated with Claude Code