Keep only the two-stage profiles and make CUDA a precondition

qwen-zimage becomes the default and sdxl-zimage the only alternative. The
controlnet, sdxl, qwen and default profiles are gone, and with them the CPU and
MPS paths for invisible-watermark removal: neither matched the two-stage
recipe's face preservation, so keeping them advertised a quality this library no
longer delivers. Visible-mark removal and every identify command still run
anywhere.

Retired names are rejected rather than remapped. Silently routing --pipeline
sdxl onward would run an old script at a different strength, on a different
model, at a different quality, and report success.

CUDA is now checked when the remover is constructed instead of when the model
loads. Auto-detection cheerfully returned mps on a Mac, so the failure arrived
several layers down, after the dependency check and the pipeline import, in a
message naming whichever internal pipeline happened to raise. _DEVICES collapses
to {"cuda"} and the cpu/mps float32 branch goes with it.

resolve_strength stays total. It briefly returned None for qwen-zimage, meaning
"ask the resolution curve", which pushed a branch onto both callers and left one
of the two strength policies outside the strength module; the CLI copy had
already grown an `or 0.0` guarding a path its own comment called unreachable. It
now takes the image size and answers for both profiles, so the displayed value
cannot drift from the executed one.

Deletion fallout removed with it: img2img_runner and progress.py (the MPS
recovery path and its progress monitor had no callers left), viable_steps, the
fp16 degenerate-output retry, the fp16 VAE fix, and the Qwen img2img call
builders. try_empty_device_cache moved into watermark_remover rather than
leaving a module whose docstring outlived its code. _HAS_DIFFUSERS routes
through optional_deps.module_available, which is what the rest of the library
uses and what correctly rejects a pruned namespace remnant.

--steps, --guidance-scale and --model now have exactly one legal value each and
are still accepted at parse time, then rejected in remove(). Their help text
says so, but validating them beside the option would be better.

Not addressed, and worth its own decision: invisible_engine forces
min_resolution to 0 for both profiles, so the --min-resolution floor, --upscaler,
_esrgan_upscale, upscaler.py and the esrgan extra are all unreachable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/cli.md

@@ -363,10 +363,15 @@ remove-ai-watermarks invisible image.png -o clean.png --force
 
 | Pipeline | When to use it |
 | --- | --- |
-| `controlnet` | Default compatibility profile with structural conditioning |
-| `sdxl` | Lighter plain SDXL regeneration |
-| `qwen` | Large CUDA oriented Qwen Image profile |
-| `qwen-zimage` | CUDA only high fidelity profile with a separate face stage |
+| `qwen-zimage` | Default. Qwen-Image-2512 global pass plus a SAM-masked Z-Image face stage |
+| `sdxl-zimage` | The same recipe and face stage on an SDXL global pass, at a higher denoise |
+
+**Both are CUDA-only.** There is no CPU or MPS profile for invisible-watermark
+removal. The former `controlnet`, `sdxl`, `qwen` and `default` profiles were removed
+rather than kept as a CPU path: none of them matched this recipe's face preservation,
+so offering them implied a quality the library no longer delivers. Passing a retired
+name is rejected at parse time rather than remapped. Visible-mark removal and every
+identify path still run anywhere.
 
 Example:
 

docs/python-api.md

@@ -389,7 +389,7 @@ from pathlib import Path
 from remove_ai_watermarks.invisible_engine import InvisibleEngine
 
 engine = InvisibleEngine(
-    pipeline="controlnet",
+    pipeline="qwen-zimage",  # the default; the only other value is "sdxl-zimage"
     device=None,
     cpu_offload=False,
 )
@@ -407,15 +407,16 @@ For limited CUDA memory:
 
 ```python
 engine = InvisibleEngine(
-    pipeline="controlnet",
+    pipeline="qwen-zimage",
     cpu_offload=True,
 )
 ```
 
-For the CUDA only high fidelity profile:
+Both profiles are CUDA-only, so `device=None` resolving to CPU or MPS cannot run
+invisible-watermark removal at all. For the SDXL global stage instead of Qwen:
 
 ```python
-engine = InvisibleEngine(pipeline="qwen-zimage")
+engine = InvisibleEngine(pipeline="sdxl-zimage")
 ```
 
 The `qwen-zimage` extra must be installed for that profile.

docs/synthid-robust-identity-research.md

@@ -246,7 +246,9 @@ from the test set + this doc).
    - If no -> the assumption is wrong; PhotoMaker would re-introduce the
      watermark. Stop and reconsider.
 2. **PhotoMaker-V1 prototype** in the existing `controlnet` pipeline:
-   - Mirror the `_load_controlnet_pipeline` path: add a PhotoMaker variant that
+   - Mirror the `_load_controlnet_pipeline` path (removed in 0.24.0 with the
+     controlnet profile; the equivalent seam is now `SdxlZImagePipeline._load_sdxl`):
+     add a PhotoMaker variant that
      loads SDXL + canny ControlNet + PhotoMaker adapter on the same engine.
    - Extract the OpenCLIP face embedding from the watermarked face crops (use
      OpenCV YuNet, already bundled for `auto`, to find the face boxes).

docs/synthid.md

@@ -514,10 +514,17 @@ study (section 2.2) gives empirical floors:
 - **Google native 2816**: 0.15 clears (n=2, deployed controlnet worker, 2026-06-14) --
   the same rung as capped 1536, so no resolution penalty was observed.
 
-The default is **vendor-adaptive** (`watermark_profiles.resolve_strength` +
-`vendor_for_strength`): the tool reads the C2PA issuer on the original input and picks
+> **Superseded in 0.24.0.** The `sdxl`, `controlnet`, `qwen` and `default` profiles
+> were removed, and `OPENAI_STRENGTH` / `GEMINI_STRENGTH` / `UNKNOWN_STRENGTH` went
+> with them. Everything from here to the end of this section is a record of what was
+> measured on those profiles, kept because the oracle verdicts are still the evidence
+> base. For the strength policy in force now see `module-internals.md`: `qwen-zimage`
+> uses `resolution_adaptive_denoise`, `sdxl-zimage` a flat vendor ladder.
+
+The default was **vendor-adaptive** (`watermark_profiles.resolve_strength` +
+`vendor_for_strength`): the tool read the C2PA issuer on the original input and picked
 `OPENAI_STRENGTH` 0.10 / `GEMINI_STRENGTH` 0.15 / `UNKNOWN_STRENGTH` 0.15 **(LOWERED
-2026-06-14 from the 2026-06-04 cert floors 0.20/0.30/0.30)**. **The SAME ladder applies
+2026-06-14 from the 2026-06-04 cert floors 0.20/0.30/0.30)**. **The SAME ladder applied
 to both pipelines** (`sdxl` and `controlnet`). The 2026-06-14 re-test on the deployed
 Modal controlnet worker (v0.10.0) cleared SynthID on the oracle at OpenAI 0.10 (2
 photoreal) and Google 0.15 (2 NATIVE 2816x1536, contradicting the "native >= 0.30" guess