Seal srv3's execution surface so no other module can name it

[briansrls]

The terminal cut of the srv3 anemic-execution dissolution. Stacked on #8769 → #8760 → #8750 → #8759.

What this closes

Any module could reach srv3_transport_witness_bin_success and srv3_elevated_witness_bin_success directly — "run this argv on this transport" and "run this argv as root on this transport". Both are now admit_callers-sealed to the functions that legitimately reach them.

The point of the whole program stated as a wall: a caller outside this module can name a semantic operation — ensure this tool, ensure this owner — and cannot name the machinery that executes it.

The seal's reach is measured, and it is narrower than the name suggests

Two probes on one build:

A caller in another module REFUSES at resolve, with the permitted set named:

error: constructor call admission refused:
  'gunbc.host_effect_realize.srv3_elevated_witness_bin_success'
  refuses call from 'test.claim.srv3_seal_probe.a_foreign_module_may_not_run_a_privileged_argv'
  — permitted callers: [gunbc.host_effect_realize.srv3_privileged_apt_install,
                        gunbc.host_effect_realize.srv3_chown_then_read_back,
                        gunbc.host_effect_realize.websocat_stage_ensure_directory]

A caller in THIS module, absent from the admitted list, calling the elevated form with ["/bin/rm", "-rf", "/"] — typechecked and resolved with no diagnostic at all.

So the rung is mechanically preventable at the module boundary and nothing within it. Reporting only the refusal would be the rung inflation §4b calls worse than sitting low, so both halves sit beside the seal with the next-rung trigger: admission checked per caller rather than per module.

A second reason that trigger matters

The admitted lists were derived by walking the module, not by reading the call sites. My first hand-read attributed two calls to the wrong enclosing function and invented a fifth caller that does not exist. Because in-module admission is unchecked, nothing would have caught either — a list the compiler does not verify is a list nothing verifies.

On the probes

Both were removed after measurement. An admission refusal is a resolve-time error, so it cannot be enrolled as a passing witness without breaking the corpus it proves — the same reason product/pcb/stackup.dag records its seal receipt in prose rather than in a test. This is a real gap in §4b(4)'s "evidence stays enrolled", and it is a property of the mechanism rather than a choice I made: what keeps the wall honest in the enrolled suite is that every route to these functions runs through an admitted caller.

Scope

No behaviour change. The same functions run the same commands for the same callers; what changed is who else may name them.

[gunbai-bot]

Fixed rather than deferred, on the one item review 54403 flagged as residue.

The review called the surviving "/bin/chmod" literal "consistent with the rest of the file and outside this cut's scope." It is the last one in the chain — sudo, chown, mkdir, stat and id all got their authority in this stack — and leaving one of six is exactly what makes the class get re-derived later. The operator's standing instruction on this program is that a string in this position is anemic modeling and that the debt is mine to own, so the scope argument cuts the other way here.

extdeps.tools.chmod cites POSIX and carries the absolute path for the same reason chown and mkdir do: a sudoers NOPASSWD rule names a command by path, and chmod sits at /bin rather than /usr/bin on the hosts this actuator targets — a fact about those hosts, recorded rather than assumed at a call site.

The mode is symbolic, and the module says why: +x adds the execute bit to whatever permissions the file carries, while an octal mode replaces the whole set. Those are not interchangeable spellings of "make it executable" — one preserves the other bits and one silently decides them — and an ensure means the additive one. The witness asserts that, not just the string.

One structural addition came with it: srv3_transport_argv_success, the argv-shaped sibling of the witness-bin surface. Every extdeps tool row returns a complete argv while that surface takes a binary and its tail separately, so callers were either splitting the argv apart by hand or — more often — not building one at all and passing a literal binary beside a literal args list. It is sealed to its caller like the rest of the execution surface and refuses an empty argv rather than running whatever a split of nothing produces.

After this, grep '"/bin/\|"/usr/bin/' over the module's non-comment lines returns exactly one hit, and it is a string_contains pattern in an assertion about emitted text, not a command being run.

Five witnesses green, including the new chmod row and the two websocat stages that reach it.

— sent from eager-crane-282

[gunbai-bot]

Superseded by #8796, which carries this work unchanged along with the rest of the srv3 stack and the fleet-converge capability binding. Consolidated at the operator's request (too many open PRs).

Verified before closing: every declaration, module and witness file this PR introduced is present on srv3-consolidated, and that branch is based on current main rather than on the older base this one carried.

Nothing is dropped. Review history stays here; the diff to review is now #8796.