feat(gallery): restore PBR map generation and image storage administration

[joshistoast]

Summary

Two legacy capabilities were missing from webv2.

Generate PBR Maps. The Gallery context menu offers "Generate PBR Maps" for a single selected image. It queues one utility graph with a pbr_maps node (tile size 512, no border, non-intermediate output on the gallery's auto-add board), at the front of the queue as the legacy action did, and reports enqueue, completion (refreshing the gallery) and failure. A canceled job is reported as information, not an error.

Image storage administration. Settings → Server gains an admin-only "Image storage" editor: the folder layout for new images (flat, date, type or hash, saved as image_subfolder_strategy alone), the state of the current move or recovery job with remaining count and errors, and Start Move / Recover with confirmation. Status polls only while a job runs and only while the editor is open; 403/409/422 responses surface inline. Non-admins never see the section.

The utility-graph runtime that watches a queue item by origin is now shared between the existing canvas utility path and the new submission, takes an abort signal so an account change detaches its listener and timer, and reconciles against the queue item on reconnect and at its settle timeout.

Related Issues / Discussions

Follows up the legacy parity audit behind #9803.

QA Instructions

From invokeai/frontend/webv2 (Node 22.14, pnpm 10.12): pnpm check:release passes. Performance baselines were re-recorded for byte growth only (new locale strings; the PBR graph builder joins the image-actions source set); request counts and chunk sets are unchanged. Two unrelated browser suites each failed once under heavy machine load and passed on rerun.

Mock backend (scripts/mock-backend.mjs, representative profile; /__faults?imageMoves=needs-recovery|queue-active seeds job states):

1. Launchpad → Preferences → Server → Image storage: change the layout; the status reads that 1000 images sit outside the current layout. Start Move → confirm: controls disable, after a few polls "All images are stored in the current layout" with the last job listed. With needs-recovery: interrupted-job message, Start Move disabled, Recover enabled and works. With queue-active: Start Move shows the 409 detail inline. As a non-admin the Server section is hidden.
2. Open a project, right-click a gallery image → Generate PBR Maps: a success notification appears and POST /api/v1/queue/default/enqueue_batch is sent with prepend: true. The mock never completes items, so the "ready" notice and gallery refresh need a real backend (first run downloads the PBR models).

Review

Material findings resolved: a PBR submission whose account changed during enqueue left its settlement promise unhandled; the watcher's socket listener and 30-minute timer survived an account change (both fixed with an abort signal and handlers attached before the account check); the watcher now reconciles on reconnect/timeout instead of silently timing out. Remaining limitations: the gallery refresh after a move finishes requires the Settings editor to still be open (documented in code); a utility item that stays pending past 30 minutes stops being watched without being canceled.

Compatibility / Rollout

No persisted-state or API changes. The mock backend gained the image-move and runtime-config routes for fixtures.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}