Round 27 findings (Opus parallel concurrency + frontend reviews).
Backend P1 fixes:
1. utils/datasets/llm_assist.py: the round 26 helper/advisor active
registry used a plain set, so two concurrent helper / advisor
loads of the same DEFAULT_HELPER_MODEL_REPO would both
set.add() (no-op the second time) and then the first finally
set.discard() would underflow the registration while the second
call was still mmap'ing the GGUF. Switch to a Counter with
proper refcount increment/decrement so the repo stays registered
until the last user releases it.
2. routes/inference.py _release_chat_for and
core/inference/diffusion.py _release_chat_backend_for_diffusion:
helper/advisor GGUF runs on a PRIVATE LlamaCppBackend (round 26
P1 #1), so the global llama checks below could not see them.
A user-driven /training/start, /export/load-checkpoint, or
/images/load would skip the unload and allocate FLUX VRAM on top
of the helper's resident weights, OOMing on 16-24 GB consumer
GPUs. Both release paths now consult helper_advisor_busy() and
fail 503 (or RuntimeError for the in-backend path) so the user
retries instead of double-owning VRAM.
Frontend P2 fixes:
3. studio/frontend/src/features/images/images-page.tsx: handleUnload
now calls refreshStatus() in the catch path so a partial unload
(503 from the backend) does not leave the UI showing a stale
"Loaded:" label. Matches the handleLoad pattern.
4. images-page.tsx: when status.is_loading is true, auto-poll
refreshStatus every 2 s so the user sees real progress instead
of a frozen "Loading..." label until they manually click Refresh.
5. images-page.tsx: aria-label="Inference steps" / "Guidance scale"
on the two sliders so screen readers can announce them.
6. images-page.tsx: defensive (r.guidance_scale ?? 0).toFixed(1)
in the results caption so a future backend that serialises
NaN/None for guidance does not throw at render.
Tests: 105 targeted (diffusion + cached_gguf + inference_validation)
and 1768 broader backend tests pass locally. Frontend
`npm run typecheck` passes.
6c528fb013