Delete every knob the fixed profiles cannot honor

The CLI still advertised --model, --steps, --guidance-scale, --device and a
deprecated --auto. Each pinned a value the two surviving profiles fix -- the
model stack, the per-stage distilled schedule, CFG 1.0, CUDA -- so the only
outcome any of them had was an error raised several frames below the caller,
under a message naming an internal profile. A flag whose sole result is a
refusal is worse than no flag: it advertises a capability that does not exist,
and it lets a wrapper thread a value that will silently do nothing. They are
gone from the parser, from InvisibleEngine, and from WatermarkRemover, so the
failure is now a TypeError or a Click "No such option" at the point the caller
can act on.

The install hint was wrong in the same way. is_available() checked torch and
diffusers, then told the user to install [diffusion] -- which contains neither
DiffSynth nor the Z-Image face stage both profiles run. Following the advice
produced a second, different failure. The module list and the extra name now
live once in watermark_profiles (REMOVAL_MODULES, INVISIBLE_EXTRA) and are read
by both the CLI gate and the remover's precondition, which cannot drift apart
because they are the same tuple.

The adaptive-polish default moved out of the argument parser. It was resolved by
reading Click's parameter source, which put per-profile data in the CLI layer,
left the engine declaring the opposite default (False vs True) so a library
caller and a CLI caller on one profile got different output, and lost the polish
entirely for anything that supplies the flag non-interactively. The flag is now
tri-state (default=None) and resolve_adaptive_polish owns the per-profile
answer. The seed follows the same rule: the CLI stopped pre-resolving it.

Dead code removed with it: six scan_*_video wrappers and the _scan_video helper
none of them had a caller for, PNG_METADATA_KEYS, feather_region_composite and
the remover region path that was only reachable from a no-caller convenience
wrapper, remove_watermark_batch on both layers, try_empty_device_cache, the
_generate/_run_qwen_zimage pass-through pair, self.model_id, and the _internal
PEP 562 shim that no caller ever went through. get_device now answers cuda or
cpu only: mps and xpu travelled one frame to the same CUDA-only refusal while
costing a device probe each, and that refusal now names the resolved device, so
device=None on a CUDA-less host says 'cpu' rather than 'None'. The XPU wheel
index went with them.

Docs: README, cli, installation, python-api, supported-signals,
known-limitations and module-internals all still described the removed profiles,
the CPU/MPS/XPU ladder, a `default`->`sdxl` alias, and the wrong extra.
known-limitations still listed the retired SDXL strength ladder as current.
scripts/smoke_matrix.py and real_examples_e2e.py drove --device mps.

Next release is 0.25.0, not a patch: this removes public parameters and
narrows a published extra on top of the released 0.24.0.

pre-commit: 1) maintain.sh - exit 0 (1091 tests, Pyright 0 errors, no
vulnerabilities); 2) /simplify - 4 agents, 11 findings applied, 2 skipped
(dropping the `device` parameter entirely, which raiw-app pins; folding
diffsynth into the `diffusion` extra, which video-only callers do not need);
3) docs sync - grepped every removed identifier across README, docs/, scripts/,
.claude/; updated 9 docs; 4) CLAUDE.md - added the no-error-only-knobs rule to
.claude/rules/development.md

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

docs/python-api.md

@@ -6,8 +6,9 @@ and pipeline modules are intended for maintainers and specialized workflows.
 Dependency groups are identical for the CLI and Python API. The default install
 covers metadata extraction, normalization, verdict logic, and stripping.
 Array/pixel APIs use `pixels`; visible removal uses `visible`; DWT-DCT detection
-uses `detect`; diffusion removal uses `diffusion`; and visible video processing
-uses `video`. Video SynthID removal combines `video` and `diffusion`. Add `heif`
+uses `detect`; invisible image removal uses `qwen-zimage` and an NVIDIA GPU; and
+visible video processing uses `video`. Video SynthID removal is a separate VAE
+path that still runs on CPU and combines `video` and `diffusion`. Add `heif`
 independently when path-based pixel APIs must decode HEIC, HEIF, or AVIF. See
 the complete [feature-extra matrix](installation.md#feature-extras).
 
@@ -380,8 +381,8 @@ to 8-bit SDR.
 
 ## Remove invisible watermarks
 
-Install `remove-ai-watermarks[diffusion]` for the standard pipelines or
-`remove-ai-watermarks[qwen-zimage]` for the CUDA-only high-fidelity profile.
+Install `remove-ai-watermarks[qwen-zimage]`. Both profiles need it, and both
+need an NVIDIA GPU.
 
 ```python
 from pathlib import Path
@@ -400,8 +401,9 @@ engine.remove_watermark(
 )
 ```
 
-`device=None` selects the device automatically. Supported explicit values are
-defined by the CLI and runtime device resolver.
+`device=None` detects CUDA. The only other accepted value is `"cuda"`; anything
+else raises at construction rather than deferring a guaranteed failure to model
+load time.
 
 For limited CUDA memory:
 
@@ -412,18 +414,22 @@ engine = InvisibleEngine(
 )
 ```
 
-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:
+Both profiles are CUDA-only, so on a machine without an NVIDIA GPU `device=None`
+resolves to `cpu` and construction raises. For the SDXL global stage instead of
+Qwen:
 
 ```python
 engine = InvisibleEngine(pipeline="sdxl-zimage")
 ```
 
-The `qwen-zimage` extra must be installed for that profile.
+The `qwen-zimage` extra is required for both profiles: each runs the same
+DiffSynth Z-Image face stage.
 
-The full `remove_watermark` signature includes strength, steps, guidance,
-seeding, tiling, resolution, and postprocessing controls. Read the
-method signature in
+`remove_watermark` takes strength, seed, tiling, resolution, and postprocessing
+controls. It takes no model id, step count or guidance scale, and neither does the
+constructor: each profile pins its model stack, its per-stage schedule and CFG
+1.0, so passing one raises `TypeError` at the call rather than being accepted and
+refused several layers down. Read the method signature in
 [`invisible_engine.py`](../src/remove_ai_watermarks/invisible_engine.py) or use
 the CLI guide for the concepts.
 Defaults can differ between the Python method and CLI profile resolution, so