Restructure docs: README = what/how-to-call, DEPLOY = how-to-run

Each fact now has exactly one home, with pointers instead of copies:

README (EN+ZH):
- Drop stale workstation env (conda lightML, D:\MiniConda paths); CLI
  examples now use plain `python -m bgfilter.cli` with bash syntax.
- Performance section reduced to orders of magnitude + pointer; the
  measured workstation table moved to DEPLOY §11.
- Notes: HF-mirror workaround and models/-folder layout (both duplicated
  DEPLOY §5 verbatim) replaced with one-line pointers.
- HTTP service: env-var prose replaced with a pointer to DEPLOY §6.
- ZH parity fixes: add the missing image_url curl example; 400/413 rows
  now mention image_url/fetch limits like the EN table.

DEPLOY (EN+ZH):
- §0: supervisord management expanded to a full command set (status/
  restart/stop/start/shutdown, both log paths, manual supervisord rescue
  after a container restart, how supervisord.conf changes are applied).
- §5: cross-check veto and background-mode subsections trimmed to
  deploy-side facts + pointers to README Pipelines/HTTP service.
- §11: absorbs the workstation CPU reference table from README.

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

DEPLOY.md

@@ -53,15 +53,34 @@ provided by the AutoDL image, python at `/root/miniconda3`.
   has no systemd / boot hook, so the autostart lives in `~/.bashrc` and only fires
   when you open an **interactive shell (SSH / JupyterLab terminal)**.
 
-Talking to supervisord (socket at `~/bgfilter-supervisor.sock`, config at
-`~/supervisord.conf`):
+**Managing the service** (supervisorctl lives next to python; socket
+`~/bgfilter-supervisor.sock`, supervisord config `~/supervisord.conf`):
 
 ```bash
-/root/miniconda3/bin/supervisorctl -c ~/supervisord.conf status bgfilter   # status
-/root/miniconda3/bin/supervisorctl -c ~/supervisord.conf restart bgfilter  # restart
-tail -f ~/autodl-tmp/bgfilter.log                                           # logs (default ~/autodl-tmp)
+S="/root/miniconda3/bin/supervisorctl -c $HOME/supervisord.conf"
+$S status bgfilter      # state + uptime
+$S restart bgfilter     # restart (e.g. after editing configs/*.yaml)
+$S stop bgfilter        # stop the service (supervisord keeps running)
+$S start bgfilter       # start it again
+$S shutdown             # stop everything, incl. supervisord itself
+
+tail -f ~/autodl-tmp/bgfilter.log   # service log (dir set by --log-dir)
+tail -f ~/supervisord.log           # supervisord's own log (when the service won't start)
 ```
 
+If supervisord itself is not running — fresh container restart with no shell
+opened yet, or a stale-socket error — start it the same way the `~/.bashrc`
+autostart does:
+
+```bash
+rm -f ~/bgfilter-supervisor.sock ~/supervisord.pid
+/root/miniconda3/bin/supervisord -c ~/supervisord.conf
+```
+
+Changes to `~/supervisord.conf` itself (port, log path, …) are applied by
+re-running the deploy script — it regenerates the file and does
+`reread + update + restart`.
+
 > After editing `configs/*.yaml` (e.g. enabling `cross_check.reuse_as_seg`), run
 > the `restart bgfilter` above so the service reloads config — config is read only
 > at startup; there is no per-request switch for it.
@@ -218,39 +237,26 @@ Override the base directory with `BGFILTER_WEIGHTS_DIR`. `models/` is gitignored
 
 ### Cross-check veto (on by default)
 
-The pipeline runs a second, high-resolution matting model
-(`ZhengPeng7/BiRefNet_HR-matting`, ~425 MB) as a "second opinion" that clears
-background residue trapped between hair strands. It is **ON by default** (both CLI
-and HTTP service). **You must provision this model** (Option A or B above):
+The pipeline runs a second matting model (`ZhengPeng7/BiRefNet_HR-matting`,
+~425 MB) as an independent "second opinion" — what it does and why is in
+[README.md](README.md) → *Pipelines*. Deploy-side facts:
 
-- ⚠️ **On an offline server (`HF_HUB_OFFLINE=1`) it must be present before the
-  first request** — otherwise every default request fails, since it cannot
-  download the model at runtime.
-- Turn it off service-wide with `BGFILTER_CROSS_CHECK=0`, or override per request
-  with the `cross_check` form field (`true`/`false`).
-- The service preloads it at startup with the rest of the warm set.
-- Optional: `cross_check.reuse_as_seg: true` in the config (default **off**) makes
-  that same forward double as the segmentation mask on the birefnet backend —
-  replacing the primary seg model instead of adding to it (~20 s/image faster on
-  CPU, ~1 GB less VRAM; the redundant primary segmenter is then skipped at
-  startup). Off by default so the veto stays an independent signal.
+- It is **ON by default** (CLI and HTTP service), so **provision this model**
+  (Option A or B above). ⚠️ On an offline server (`HF_HUB_OFFLINE=1`) it must be
+  present before the first request — otherwise every default request fails.
+- Turn it off service-wide with `BGFILTER_CROSS_CHECK=0`, or per request with the
+  `cross_check` form field; the service preloads it at startup when enabled.
+- `cross_check.reuse_as_seg: true` in the config (default **off**) makes that
+  forward double as the segmentation mask: one less model loaded, ~20 s/image
+  faster on CPU, ~1 GB less VRAM. Config-only — restart to change it.
 
 ### Background mode (flat vs complex)
 
-The `/remove-background` `background_mode` form field selects the pipeline:
-
-- `flat` (**default**, also when omitted): the colour-keyed pipeline for a solid
-  flat background — unchanged behaviour.
-- `complex`: non-flat / scene background. No colour key: segmentation alone drives
-  the trimap and the colour-keyed stages (background auto-detect, hue split, chroma
-  suppression, despill) are bypassed. `screen_color` is ignored; expect flat
-  backgrounds to stay stronger on hair-level detail.
-
-No extra weights: `complex` reuses the already-provisioned BiRefNet segmenter +
-ViTMatte. The cross-check veto still works in `complex` (via a hue-free gate) but
-**defaults off** there — pass `cross_check=on` to enable it. The response echoes the
-mode used in the `X-BGFilter-Background-Mode: flat|complex` header. Full field/header
-reference is in `README.md` → *HTTP service*.
+`background_mode=complex` (non-flat / scene backgrounds) needs **no extra
+weights** — it reuses the already-provisioned BiRefNet segmenter + ViTMatte and
+bypasses the colour-keyed stages. The cross-check veto **defaults off** in
+complex mode (pass `cross_check=on` to enable it). Field semantics and response
+headers: [README.md](README.md) → *HTTP service*.
 
 ### Downloading behind a firewall (CN networks)
 
@@ -434,6 +440,21 @@ curl -H "X-Genarrative-Image-Token: <token>" \
   ViTMatte + one BiRefNet@1024, chunked attention). The **default lane** is slower —
   the cross-check adds a second HR-matting@2048 forward. Requests are serialized by
   the global lock, so plan for a handful of images/min per instance.
+- **Default lane, workstation CPU reference (Ryzen 9700X, native bf16, 32 GB;
+  cross-check on with `reuse_as_seg`, chunked attention):**
+
+  | input | precision | warm / image | peak memory |
+  |---|---|---|---|
+  | 1024×1536 | fp32 | ~45 s | — |
+  | 1024×1536 | bf16 | ~33 s | — |
+  | 2048×2048 | bf16 | ~53 s | 11.4 GB (batch), 8.1 GB (single image) |
+
+  Without `reuse_as_seg` add the primary BiRefNet@1024 forward (~+20 s/image).
+  The memory ceiling is the cross-check HR forward (fixed `input_size` 2048
+  regardless of image size). Before chunked attention the same 2048² bf16 run
+  peaked at 25.2 GB; fully un-optimized fp32 would need an estimated 55–60 GB.
+  CPUs without native bf16 (e.g. Zen 2) auto-fall back to fp32 — prefer
+  `--no-cross-check` there if memory or latency is tight.
 - For throughput: use a GPU (`BGFILTER_DEVICE=cuda`, install a CUDA torch build) —
   roughly an order of magnitude faster — and/or run multiple instances behind a load
   balancer (each with `--workers 1`).