feat(toolbox): the first four doors out of the toolbox, without a chat client on the way

B-gate row 1's premise, made callable. Every path through the framework CLI constructs a chat
client, so an outside caller -- a human at a terminal, or an agent that is NOT po -- could not
reach a single run-path step without paying for a model. These four steps need no model at all.

One CLI, four subcommands, one core call each:

  navigate-bundle  --bundle-dir                         -> okf.navigate_bundle
  cost-baseline    --bundle-dir --project-id            -> okf.derive_cost_baseline
  retrieve-chunks  --query --docs-dir [--top-k]         -> datasource.retrieve_chunks
  prepass-admit    --payload --bundle-dir [--dimension] -> prepass.admit_payload

Each handler is a thin adapter: strings in, the SAME function the run path calls, JSON on stdout,
and an exit code that says what happened (0 ran, 2 malformed call, 3 the step refused, named).
A handler that computed anything of its own would be a second implementation of a run-path step,
and the outside caller would stop getting what the debate gets.

Dispatch is an explicit branch per command, not argparse's `set_defaults(handler=...)`: the table
hides the one thing a reader wants to see, and B-gate row 1 asks the same question of the source
(it walks the call graph from `main` down to the step's symbol), where a callable in a Namespace
is a hop neither can follow.

Probes (`tests/test_toolbox_doors.py`, 10 arms): each starts the door as a SUBPROCESS with the
subcommand in argv and asserts on what it wrote -- never by importing the core function, which is
the whole difference the gate exists to measure. The yardstick is outside the door in every arm:
the filesystem (navigate-bundle, including the one deliberate outside-bundle link), a table
transcribed from the priced fixture (cost-baseline), the in-process seam it must equal byte for
byte (retrieve-chunks), and the producer's own checked-in payload (prepass-admit). Every refusal
arm has an rc-0 control beside it.

`portfolio-optimiser-toolbox` is the THIRD console script, and the pin test now says why: it is
the door the other two cannot be used for. README and CLAUDE.md updated with the command and the
reason it exists; every documented invocation was run.

Row 1: 1 -> 5 of 17 (four subcommands + `gate`, which the class fix in e47be68 stopped rejecting
on a name technicality). No other row moved; exit 1.

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

README.md

@@ -72,10 +72,38 @@ Both are tag-pinned deliberately: they are security components, and a version th
 an install is a gate that can stop gating without a local diff. `uv sync` from a clone reads the
 pins from `pyproject.toml`, which is why the source path above needs none of this.
 
-`uv sync` installs two commands: `portfolio-optimiser` (the CLI) and `portfolio-optimiser-demo`
-(the offline end-to-end proof). They are equivalent to the `python -m portfolio_optimiser.run` and
-`python -m portfolio_optimiser.simulation` forms used throughout this README, which keep working —
-the module form is spelled out below so a reader can see which module answers a given command.
+`uv sync` installs three commands: `portfolio-optimiser` (the CLI), `portfolio-optimiser-demo`
+(the offline end-to-end proof) and `portfolio-optimiser-toolbox` (the run-path steps as plain
+commands). They are equivalent to the `python -m portfolio_optimiser.run`,
+`python -m portfolio_optimiser.simulation` and `python -m portfolio_optimiser.toolbox` forms used
+throughout this README, which keep working — the module form is spelled out below so a reader can
+see which module answers a given command.
+
+### The toolbox: run-path steps without a model
+
+Every path through the CLI above builds a debate, and therefore a chat client. The steps the
+debate is built *on* need no model at all, and `portfolio-optimiser-toolbox` exposes them so an
+outside caller — you at a terminal, or an agent that is not this framework — can drive them
+directly. No model call, no network, JSON on stdout, and an exit code that says what happened:
+`0` the step ran, `2` the call was malformed, `3` the step refused and the refusal is named.
+
+```bash
+# Open a knowledge base and report what navigation reached (and every link it could not follow)
+uv run portfolio-optimiser-toolbox navigate-bundle --bundle-dir shared/examples/bygg-energi-mikro
+
+# Retrieve citation-ready chunks — the same call the agents' in-process tool makes
+uv run portfolio-optimiser-toolbox retrieve-chunks \
+  --query "LED retrofit" --docs-dir shared/examples/bygg-energi-mikro --top-k 2
+
+# Derive the cost baseline from a priced schedule already in the base
+uv run portfolio-optimiser-toolbox cost-baseline --bundle-dir <base> --project-id <id>
+
+# Admit (or refuse, by name) a declared pre-pass cut before it may shape a run
+uv run portfolio-optimiser-toolbox prepass-admit --payload <cut.json> --bundle-dir <base>
+```
+
+Each subcommand calls the same function the run path calls — not a copy of it. That is what makes
+the answers you get here the answers the debate gets.
 
 Verify the install by running the whole suite from the clean clone: