docs: name bot-bottle, not ./cli.py, in every instruction

`doctor` told users to run `./cli.py backend setup`. cli.py is a four-line
wrapper at the repo root that calls bot_bottle.cli:main, and it does not ship —
[tool.setuptools.packages.find] includes only bot_bottle*, so anyone who
installed rather than cloned has no such file. Confirmed against a real
install: the user's tree contains exactly one executable, `bot-bottle`, and no
cli.py anywhere, while doctor recommended `./cli.py` three times. Invisible in
development, where ./cli.py works fine from a checkout, which is why only a
clean-install test surfaced it.

The two entry points are the same code, so the fix is to name the one that
always exists. 141 replacements across 45 files: the runtime messages that
caused this, plus README, docs, PRDs, research notes and test prose, so nothing
teaches the invocation a user cannot run.

scripts/demo.sh is deliberately untouched — it *executes* ./cli.py from a
checkout, where that is the correct and available path.

Verified end to end: a sandbox install now reports
"Run: bot-bottle backend setup --backend=firecracker", and bot-bottle is on
that user's PATH. Unit suite unchanged against the pre-existing baseline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5

tests/README.md

@@ -95,7 +95,7 @@ BOT_BOTTLE_RUN_CANARIES=1 python -m scripts.unittest_gate \
    ```
 4. Skip guards live in `tests._backend` and gate on the backend's own
    readiness check, `bot_bottle.backend.has_backend` — the same probe
-   behind `./cli.py backend status`:
+   behind `bot-bottle backend status`:
    - Backend-agnostic tests (go through `get_bottle_backend()`) decorate
      the class with `@skip_unless_selected_backend_available()` — the test
      runs against whichever backend `BOT_BOTTLE_BACKEND` selects and skips
@@ -105,7 +105,7 @@ BOT_BOTTLE_RUN_CANARIES=1 python -m scripts.unittest_gate \
      `backend.docker.*`, …) decorate with `@skip_unless_backend("docker")`
      so they no-op under a run targeting a different backend.
 
-   Each CI integration job runs `./cli.py backend status --backend=<name>`
+   Each CI integration job runs `bot-bottle backend status --backend=<name>`
    as a preflight, which prints a clear per-check summary and exits non-zero
    when the backend is missing — so absent infrastructure fails the job
    instead of hiding among per-test `unittest.skip` lines.

tests/_backend.py

@@ -2,7 +2,7 @@
 
 Each integration test targets the backend named by ``BOT_BOTTLE_BACKEND``
 (default ``docker``) and gates on that backend's full readiness check —
-``is_backend_ready()`` (equivalent to ``./cli.py backend status``), not just
+``is_backend_ready()`` (equivalent to ``bot-bottle backend status``), not just
 a binary-on-PATH probe. When the backend is not ready, diagnostic output is
 printed during test discovery so the operator sees a concrete reason for each
 skip.

tests/unit/test_backend_skip_guards.py

@@ -1,7 +1,7 @@
 """Tests for the backend-aware skip guards in ``tests/_backend.py``.
 
 The guards delegate their readiness check to
-``bot_bottle.backend.is_backend_ready`` (the probe behind ``./cli.py backend
+``bot_bottle.backend.is_backend_ready`` (the probe behind ``bot-bottle backend
 status``); here that probe is mocked so the unit job asserts the
 selection/skip logic without either backend present on the runner.
 """

tests/unit/test_cli_backend.py

@@ -1,6 +1,6 @@
 """Unit: the generic `backend` CLI command.
 
-`./cli.py backend {setup,status} [--backend=NAME]` resolves a backend
+`bot-bottle backend {setup,status} [--backend=NAME]` resolves a backend
 and dispatches to its `setup()` / `status()` classmethods — no
 backend-specific commands. Also covers the docker backend's own
 setup/status logic (the firecracker path is exercised by