fix: make installed wheel self-contained + harden install.sh prereqs

Addresses the review on PR #481.

Self-contained wheel (review point 1): the gateway/infra/orchestrator
images build from a context that must hold bot_bottle/, pyproject.toml,
and the root-level Dockerfiles. Modules previously located these by
walking __file__ to the repo root, so an installed wheel (package in
site-packages, no repo root) passed `doctor` but failed `start`.

- Add bot_bottle/resources.py: build_root() returns the repo root in a
  checkout (unchanged) or a staged copy from the wheel's bundled
  _resources/ otherwise; dockerfile()/nix_netpool_module()/
  netpool_script() derive from it.
- setup.py bundles the root Dockerfiles, nix module, netpool script, and
  pyproject.toml into bot_bottle/_resources/ at build; MANIFEST.in ships
  them in the sdist.
- Route every _REPO_ROOT/_REPO_DIR call site (docker/macos launch, macos
  infra, firecracker infra_vm/infra_artifact/setup, orchestrator
  lifecycle/gateway) through resources. Checkout behavior is unchanged.

install.sh prerequisites (review point 2): check for git when installing
a git+ spec, and — before the pip fallback — that pip is usable and the
interpreter isn't externally managed (PEP 668), pointing at pipx.

Tests: test_resources covers checkout + staged-wheel layouts;
test_wheel_install builds the wheel, installs it into an isolated venv,
and asserts `doctor` runs and build_root() yields a valid context.
Running `start` end-to-end still needs a Docker/KVM host (CI).

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

docs/prds/prd-new-install-script.md

@@ -67,10 +67,54 @@ bot-bottle = "bot_bottle.cli:main"
 ```
 
 `bot_bottle.cli:main` already exists (the `cli.py` shim calls it), so no
-refactor of the entry point is needed. `package-data` ships the container
-Dockerfiles, `egress_entrypoint.sh`, the firecracker netpool defaults, and
-the macos-container init script so an installed wheel can still build its
-sidecar/agent images.
+refactor of the entry point is needed. `package-data` ships the non-Python
+assets that live *inside* the package (`egress_entrypoint.sh`, the contrib
+Dockerfiles, the firecracker netpool defaults, the macos-container init
+script).
+
+### Self-contained wheel (build resources)
+
+The gateway / infra / orchestrator images are built from a Docker (or Apple
+`container`) build context that must contain the `bot_bottle` package,
+`pyproject.toml`, and the **root-level** Dockerfiles as siblings. Several
+modules used to locate that context by walking `__file__`'s parents to the
+repo root (`_REPO_ROOT = Path(__file__)…parents[N]`) and reading
+`Dockerfile.gateway`, `nix/firecracker-netpool.nix`, and
+`scripts/firecracker-netpool.sh` from it. In an installed wheel the package
+lives in `site-packages` with no repo root above it, so those reads fail —
+`doctor` passes but `start` / backend setup breaks.
+
+Fix: a single resolver, `bot_bottle/resources.py`.
+
+- `build_root()` returns a directory shaped like a repo root (has
+  `bot_bottle/`, `pyproject.toml`, the Dockerfiles, `nix/`, `scripts/`).
+  In a **checkout** it's the repo root itself — unchanged behavior. From an
+  **installed wheel** it stages a copy under the app-data dir, keyed by a
+  **content digest** of the installed package + bundled resources (not the
+  distribution version): the installer defaults to a git branch and
+  `pipx install --force` while `version` stays `0.1.0`, so a version key
+  would reuse a previous commit's tree — the digest key re-stages instead.
+  Staging is concurrency-safe: a file lock serializes it, each writer builds
+  into a private temp dir, and the finished tree is published with an atomic
+  rename (never populating a shared path another process might read).
+- The root-level resources are shipped inside the wheel under
+  `bot_bottle/_resources/` by a `setup.py` `build_py` step (kept in sync
+  with `resources.BUNDLED_RESOURCES`); `MANIFEST.in` includes them in the
+  sdist.
+- Every former `_REPO_ROOT` / `_REPO_DIR` call site now derives from
+  `resources`: the docker/macos agent-image launch, each backend's
+  `orchestrator` / `gateway` / `infra` service, firecracker `infra_vm` /
+  `infra_artifact` / `setup`, and the shared `gateway` build context. So
+  checkout and wheel installs share one downstream path.
+
+Verification: `test_resources` exercises both layouts — including the staged
+wheel context, a re-stage when package content changes at the same version,
+and a rebuild of a partial (crashed) stage. `test_wheel_install` builds the
+wheel, installs it into an isolated venv, and asserts `bot-bottle doctor`
+runs and `build_root()` produces a valid context; `build` is in
+`requirements-dev.txt` so it runs in CI, and a build/install failure fails
+the test (it does not skip). Running `start` end-to-end still needs a
+Docker/KVM host (CI), not a source checkout.
 
 ### `install.sh`
 
@@ -78,8 +122,11 @@ A POSIX `sh` bootstrapper that:
 
 1. Checks `python3` is present and ≥ 3.11; exits with a clear message
    otherwise.
-2. Creates `~/.bot-bottle/{agents,bottles,contrib}`.
-3. Installs via `pipx` if available, else `python3 -m pip install --user`.
+2. Checks `git` when installing a `git+` spec, and — when falling back to
+   pip — that pip is usable and the interpreter isn't externally managed
+   (PEP 668), pointing at pipx otherwise.
+3. Creates `~/.bot-bottle/{agents,bottles,contrib}`.
+4. Installs via `pipx` if available, else `python3 -m pip install --user`.
    The spec defaults to the git URL and is overridable via
    `BOT_BOTTLE_INSTALL_SPEC` (used by tests / local installs).
 4. Locates the `bot-bottle` entry point (PATH or `~/.local/bin`).