Add an executor benchmark that keeps its results

Choosing a local executor model, and tuning its knobs, needs measured
success rates across repeated runs, comparable with every model
measured before.

- Four canned milestones under nisse_dev/bench/tasks: write a function,
  fix a bug a failing test exposes, thread an option through several
  files, and find one failure in output far past max_output_chars. Each
  is an approved plan over a seed project, judged by a hidden check the
  model never sees; a reference solution proves each is solvable and
  that its check tells the difference
- Runs use the agent's own client wiring, now shared as
  make_llm_clients, with delegation and ask_expert off: an escalation is
  a failure of the model under test
- Each run is stored as one JSON line in bench/results/, committed, with
  the model's backing name and declared facts, a note on how it was
  served, the task's content hash, the agent's commit and tuning, the
  outcome, turns, misbehaviour counts, context trims, tokens, time and
  LiteLLM's cost; a fallback answer can never count as a success
- The report rebuilds the comparison from every stored run, with Wilson
  95% intervals, marking runs against older task versions
- scripts/benchmark.py runs and reports; scripts/evaluate_model.sh takes
  a new model through the context probe, the capability matrix and the
  benchmark in one command
- Clients keep LiteLLM's per-call cost, and BudgetedClient counts the
  requests it had to trim
- The tuning guide gains "Benchmarking models"

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

nisse-dev/src/nisse_dev/bench/__init__.py

@@ -0,0 +1,17 @@
+"""The executor benchmark: canned milestones, run repeatedly per model.
+
+Choosing an executor model, and later tuning its knobs, should rest on
+measured success rates, not on one run or on reputation. Each task is a fixed
+approved plan over a seed project, with a hidden check the model never sees;
+success means the check passes, not that the model said it finished. Runs use
+the agent's own client wiring (context budget, declared limits, tool_choice
+only where declared), so what is measured is what the agent would do.
+
+Results are stored, one JSON line per run, with everything needed to compare
+them later: the model's identity and declared facts, a note on how it was
+served, the task's content hash, the agent's commit, and its tuning. A new
+model then needs only its own runs to be compared with everything measured
+before it.
+
+See scripts/benchmark.py, and docs/Tuning-Guide.md for how to read results.
+"""