feat(agent-interface): give the improvement surfaces and the native reasoning control one owner

[drewstone]

Two vocabularies in this package were each owned in two places. Both had already drifted; one of the drifts refuses live runs today.

1. Improvement surfaces

AgentImprovementSurface and the promotion schema's improvementSurfaceSchema enum were two hand-written copies of the same list. They are now one exported AGENT_IMPROVEMENT_SURFACES, with the type derived from it and the enum reading it.

The list gains rollout-policy. agent-runtime's ImproveSurface carries rollout-policy and implements it end to end (profile-surface.ts:78 reads it, :260 applies it, agent/surfaces.ts:201 resolves its path), but AgentImprovementSurface had no such member — so a rollout-policy improvement could be produced and never named in a proposal, which is what carries it to a review or a gate.

2. Native reasoning control

nativeReasoningControl(harness, effort) returns the exact control token a harness process receives. That is the value a materialization receipt carries as reasoningEffort.applied, so both sides of the receipt check now read one table:

harness	control	source read
claude-code	--effort value; none/minimal clamp to low, ultracode → max	cli-bridge claudeEffort
codex	model_reasoning_effort value; ultracode → ultra, the rest canonical	cli-bridge codexReasoningEffort
pi	--thinking value; none → off, ultracode clamps to xhigh	cli-bridge thinkingFlagForEffort
prime	--thinking value; none → off, ultracode → max	agent-profile-materialize PRIME_THINKING_BY_EFFORT
kimi-code	the flag itself, --thinking / --no-thinking; medium passes none	cli-bridge thinkingFlagForEffort
opencode	the canonical rung unchanged	cli-bridge opencodeVariantForEffort
every other harness	null — no thinking flag is plumbed	cli-bridge profile-support.ts:128

The drift this closes

agent-runtime's private copy (expectedBridgeAppliedReasoning) expects codex to apply minimal for none, and high for both xhigh and ultracode. cli-bridge 0.3.0 applies none, xhigh and ultra. The comparison throws ValidationError, so three of the seven rungs refuse a legitimate codex run today.

Its default arm also asserts that every unlisted harness applied the canonical rung. Eleven harnesses fall in that arm and none of them plumbs a thinking flag — five are already named in this file's own harnessIgnoresEffort set — so each receipt reports applied: null against an expectation of the request, and the run is refused.

The interface docstring for pi also claimed a max rung. The pi line's allowlist stops at xhigh; corrected here.

Tests

Four cases in harness-capabilities.test.ts: the pinned per-harness ladder mapping, null for every harness with no native control, null for an unrequested effort, and a cross-check that no harness in harnessIgnoresEffort is ever claimed to have applied one.

pnpm check-types, pnpm test (91 files), pnpm build, pnpm check:package-artifacts and pnpm check:control-artifacts all pass.

Consumers

agent-runtime deletes its private switch and calls this function (tangle-network/agent-runtime#954 items 3 and 4). A follow-up in cli-bridge replaces its per-backend copies with the same call.