fix(analysis): harden readiness gate and vision-manager per self-review

Backend:
- Log on readiness state transitions (ready<->not-ready) so a misconfigured
  ANALYSIS_VISION_HEALTH_URL, which otherwise parks the worker silently
  forever, is diagnosable.
- Add unit tests for HttpVisionReadiness: 2xx->ready, non-2xx->not-ready,
  connection error->not-ready (the production status mapping had no test).

vision-manager:
- Guard the backlog count against non-numeric output before `-gt`, so a stray
  value can't exit-2 and kill the loop under `set -e`.
- Throttle the crawl-mutex "deferring start" log to once per episode.
- Only reset the idle/uptime timers when `docker stop` actually succeeds, so a
  failed stop retries next tick instead of waiting a full debounce window.
- Decouple the per-probe curl timeout (HEALTH_TIMEOUT) from the warm-up poll
  cadence.

Docs:
- Correct the docker-socket-proxy comment: CONTAINERS+POST permits the full
  container lifecycle (not just start/stop); state the real trust boundary.
- Document that the externally-defined mangalord-vision container must share
  the compose network for name resolution.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

VISION-AUTOSCALE.md

@@ -16,6 +16,15 @@ container lifecycle: start it when work appears, stop it when work is gone.
 > still-loading vision never burns a job's retries or writes a `failed` row
 > (the gotcha called out below). Configure via the `ai`-profile vars in
 > [.env.example](.env.example).
+>
+> **Operator prerequisite:** the `mangalord-vision` container is defined
+> *outside* this compose project (the manager only drives it by name). For the
+> manager and backend to resolve it by name for the `/health` probe, attach it
+> to this project's default network (`<project>_default`, e.g.
+> `mangalord_default`) — or point `VISION_HEALTH_URL` /
+> `ANALYSIS_VISION_HEALTH_URL` at an address that resolves. If the container is
+> unreachable the manager silently treats it as "not running / not ready" and
+> will loop trying to start a container it cannot see.
 
 ## Chosen approach — Option 2: a "vision-manager" sidecar