refactor(supervise): delete piExecutor — no harness gets a bespoke executor

[drewstone]

−3,360 / +50 across 16 files. cli-bridge already routes pi generically (matches(m) => m === 'pi' || m.startsWith('pi/')), so a second pi-only code path was duplication. A pi worker is now createExecutor({ backend: 'bridge', model: 'pi/<provider>/<model>' }) — the same call every other harness uses.

BREAKING, released as 0.118.0.

What went

Both source files (pi-executor.ts 880, pi-mcp.ts 534), both test files, 15 public exports, the { backend: 'pi' } ExecutorConfig arm with its three switch cases, and the registry's pre-registered 'pi' runtime. The brief named 8 exports; the other 7 came from the same pi-mcp block and were found by compiling, not by grepping.

Two sites the compiler found that a grep would have missed

1. supervise.ts:187 classified backend: 'pi' as promptModelProfileMaterialization — prompt-and-model only, matching what piExecutor documented itself as dropping. Removing that arm means pi now falls under fullProfileMaterialization. That is the profile-fidelity upgrade made enforceable: a profile that changes reasoningEffort, tools, or resources is now honored instead of silently rejected at workerFromBackend.
2. worker-trace.ts holds WORKER_TRACE_PROPAGATION ... satisfies Record<ExecutorConfig['backend'], boolean>. Its pi: true row became an excess property the moment the arm went, along with two prose lines naming PiSeam.env and a backend count that was off by one.

Migrated, not deleted

tests/runtime/executor-config-snapshot.test.ts — the pi case asserted that an ExecutorConfig is captured at its call boundary. That behaviour still exists for pi on the generic path, so the case became pi-over-bridge with a real pi wire id. Zero assertions lost.

src/runtime/environment-provider.test.ts was listed in the brief as a consumer and is deliberately untouched — its backend: 'pi' is the BackendType on the provider input, not ExecutorConfig.backend. 'pi' remains a valid harness; only the bespoke executor is gone. Editing it would have destroyed real provider-path coverage.

The 49 deleted it() blocks went with their subject: they test the pi RPC protocol adapter and the --mcp-config writer, neither of which exists here any more. cli-bridge has its own implementations with its own tests.

What improves, and what regresses

Better — all four were dropped outright by the old executor: reasoningEffort → --thinking, profile.tools → --exclude-tools, profile.resources materialized, systemPrompt as a native --system-prompt file rather than glued onto the task text.

Worse, stated in the changelog so nobody is surprised — mid-turn steering degrades (the bridge runs pi as --print --mode json with stdin closed, so a steer lands after the run and an interrupt is a process-tree kill); PiSeam.args/env/per-worker bin have no wire equivalent; WORKER_TRACE_PROPAGATION loses its pi: true row, so a pi worker no longer inherits TRACE_ID/PARENT_SPAN_ID.

progress() and traceSource() are absent on bridgeExecutor — for every harness, not just pi. Fixed in #687, which should land first.

Downstream, none broken until they upgrade

• loops (pinned 0.111.0) — src/pi-worker.ts, extensions/pi/loops.ts. The real migration; steering is a behaviour change, not just a call-shape change.
• supervisor-lab (pinned 0.116.0) — bench/deepswe/live.ts:193, one call site.
• agent-eval-runtime-run-reader — two test files.

Not edited here, so the release can be sequenced.

Gates, re-run independently

tsc 0 · examples tsc 0 · 2227 passed / 6 skipped across 197 files · biome clean (535 files) · docs:check OK, no drift · check:testing-fixture current · merges clean into origin/main, 0 behind.