Operations: Add a typed, resumable privileged dogfood runner

[blue-az]

Depends on: #7

Objective

Replace the high-volume manual sudo relay used during Issue #7 dogfood with a typed, resumable, root-owned administrative runner without weakening the P3 authority boundary.

The runner belongs in this repository but remains a separate administrative module and command surface. It is operational tooling, not part of the broker protocol or the P3 security claim.

Scope

• Add a separate module such as dogfood_runner.py, exposed only through operator-admin dogfood-plan, dogfood-run, dogfood-status, and dogfood-resume.
• Accept a strict canonical plan containing only enumerated operations and typed arguments. Bind every run to the plan digest, installed release digest, ledger identity, policy binding, and fixed host paths.
• Execute bounded phases for installation verification, service lifecycle, privilege evidence, enrollment, reconciliation, rotation, outage/recovery, revocation checks, and final audit.
• Require explicit administrator approval before each mutating phase while allowing the phase's read-only assertions to run together.
• Persist root-owned run state, checkpoints, receipts, command outcomes, and append-only evidence under a dedicated path such as /var/lib/operator-control-plane-admin/dogfood-runs/, separate from broker-owned authority state.
• Make exact retries idempotent and resume only from explicit durable checkpoints. Record incomplete, failed, recovered, and completed phases distinctly.
• Run exclusively from the installed root-owned interpreter/code path with a sanitized environment and safe working directory.
• Provide dry-run/plan inspection and machine-readable status output that an unprivileged supervisor can audit without gaining mutation authority.
• Document the review, execution, interruption, recovery, and evidence-export workflow.

Security boundaries

• No arbitrary shell strings, shell expansion, user-supplied executables, worktree imports, or general-purpose command escape.
• No password piping, expect, credential capture, broad NOPASSWD, or reusable sudo capability for builder/verifier accounts.
• No automatic user/group provisioning, sudoers edits, polkit edits, sysctl changes, container/service delegation, or host-hardening decisions. Those remain explicit administrator work outside the runner.
• The runner must not run the broker as root, write broker-owned authority state directly, bypass SO_PEERCRED authorization, weaken policy, or manufacture successful evidence after a failed phase.
• A plan replacement, digest mismatch, unknown operation/field, unsafe path, symlink, hard link, wrong ownership/mode, stale checkpoint, or incompatible installed release fails before mutation.

Acceptance

1. A reviewed canonical plan can execute a complete disposable-ledger dogfood sequence through bounded phases with substantially fewer manual relays.
2. Unknown operations/fields and arbitrary-command attempts fail before any state change.
3. Plan, release, ledger, policy, and run-state bindings cannot be replaced or redirected by cwd, environment, symlink, local repo state, or an agent UID.
4. Exact phase retries are idempotent; interruption at every mutation checkpoint resumes without duplicate authority commits, policy events, projections, or evidence records.
5. Failed assertions stop the phase and preserve an explicit recovery path. Resume cannot skip a failed required gate.
6. Run-state and evidence writes are atomic, durable, race-resistant, and independently auditable.
7. Builder/verifier accounts remain unable to invoke privileged phases or gain sudo/root/broker authority through the runner.
8. Focused tests cover plan parsing, authorization, path attacks, interruption/recovery, idempotency, and evidence integrity; guarded real-root tests exercise the installed boundary.
9. A real disposable-ledger run demonstrates review, execution, interruption, resume, final audit, and evidence export before the runner is recommended for a production ledger.

Non-goals

• Reopening or expanding Issue P3d: Migrate ledgers and dogfood the authority boundary #7's P3 authority claim
• Provisioning operating-system identities or changing host security policy
• General workflow orchestration, rooms, UI, remote execution, or arbitrary command automation
• Eliminating human approval for privileged mutation
• Automatically enrolling ~/.operator-usage or another production ledger

Stop condition

Do not claim the runner reduces the privilege boundary merely because it reduces copy/paste. It is complete only when the installed root-owned path, typed-operation restriction, crash recovery, and agent-UID denial are independently proven.