Verify the hosted fountain path end to end once the acp runtime lands

[lex00]

#2127 and #2129 each carried one acceptance item that could not be checked offline, and a live run against a real fountain v0.16.0 instance got most but not all of the way.

What that run proved: all six kinds apply, a second apply is idempotent for the kinds chant reconciles, the roster and schedules read back correctly, and lifecycle diff --live reports a paused schedule and nothing else. It also found #2166 and #2167, both fixed.

What it could not reach, and why:

• A real turn, the thread, and the gated apply (examples/fountain-steward/README.md sections 3 to 5). Blocked twice over: the agent create is rejected until An acp runtime: launch a named ACP command with no model, so a deterministic program can run as an agent BinaryBourbon/fountain#1634 makes runtime: "acp" valid and model optional, and the laptop's spritzer emulator answers initialize is not supported rather than speaking ACP, so it needs a real sprites data plane as well.
• An Environment with networking_type: limited fails provision on that emulator with {:network_policy, {:invalid, {:http, 200, %{"rules" => …}}}}. That looks like the emulator rather than chant, but it was not reproduced against a real data plane, so it is unattributed rather than filed upstream.

Re-run the README walkthrough when #1634 has shipped and a sprites-backed instance is available. fountain-ops stands the instance up; note INTENTIUS/fountain-ops#119, its default image pin is nine releases behind.

Acceptance

• A steward agent applies with runtime: "acp" and no model.
• chant run <op> --on fountain completes a turn, and the thread shows one tool call per step.
• A gated op ends the turn pending approval, and answering it completes the run.
• The limited networking case is either shown to work or filed upstream with real-plane evidence.
• The README's sections 3 to 5 match what actually happens.

[lex00]

Checked on 2026-09-06 while closing out the other Temporal-to-fountain leftovers (#2176, #2178, #2179). Still blocked, left open on purpose.

• An acp runtime: launch a named ACP command with no model, so a deterministic program can run as an agent BinaryBourbon/fountain#1634 (the acp runtime with no model) is still open. fountain's latest release is v0.16.0 from 2026-09-03, which is the version the earlier live run was against, so the agent create is still rejected on both runtime and model.
• No sprites-backed data plane is reachable from here, and the spritzer emulator still answers initialize is not supported in place of ACP, so sections 3 to 5 of the README cannot be exercised and the limited networking case cannot be attributed.
• The default image pin is v0.7.0, nine releases behind, so just up stands up an instance without team, schedules or webhooks fountain-ops#119 (the image pin nine releases behind) is also still open, so just up there would not produce a usable instance either.

None of the five acceptance items can move until #1634 ships and an instance with a real data plane exists. Nothing in chant changes for this issue in the meantime.

[lex00]

The approve re-run path changed in #2192, so the third acceptance item here now tests different behaviour than it did before.

Before: chant run approve <op> <gate> --on fountain posted the prompt chant run approve <op> <gate> onto the steward's thread. The ACP command parser (lexicons/fountain/src/acp/command-line.ts) reads that as the approve verb, not as an op run, so the sandbox wrote the same gate resolution a second time on its local runtime and printed "re-run chant run <op>". The op was never re-applied, although three docs pages said it was.

After: the posted prompt is chant run <op>, still carrying --approver <resolvedBy> and --url <url>. The parser reads that as kind: "op-run", so the sandbox re-runs the op, evaluateGate reads the resolution off the ledger branch, and the run walks through the gate.

What was verified offline, in lexicons/fountain/src/op/runtime.test.ts:

• the exact prompt string posted to POST /api/conversations/:id/prompts is chant run alb-deploy --approver alex --url https://github.com/o/r/pull/1;
• that same string, fed to parseChantCommandLine, parses as kind: "op-run" with op: "alb-deploy", args.approver: "alex" and args.url set. This runs core's own parseArgs and resolveCommand, so it is the real parser rather than a stub.

What was not verified, and needs the live run this issue tracks:

• that the sandbox's own chant run <op> reaches the gate ledger branch at all from inside the sandbox (it reads chant/lifecycle through git, and whether that orphan branch is fetched in the sandbox's checkout is untested here);
• that the re-run's turn completes rather than gating again, which is what the "answering it completes the run" acceptance item above actually asks;
• whether a second turn on the same thread hits conversation_busy in practice when the approve command is issued while the first turn is still settling.

The walkthrough in examples/getting-started/README.md was also rewritten for the new path: the redundant local chant approve before chant run approve ... --on fountain is gone (the latter writes the same ledger fact itself), and it now closes with chant run status <op> --on fountain. That closing step is also unverified against a live instance.