command_runner: the import #8919's builder call needs, and the census that closes the class at two

[gunbai-bot]

One import line. #8919 replaced a hand-built argv at command_runner.dag stat_owner_name_capture with the builder extdeps.tools.stat stat_owner_user_name_command, and did not add the import the call needs.

 import extdeps.shell
+import extdeps.tools.stat { stat_owner_user_name_command }
 import std.algebra { Empty }

The call site is correct and is exactly what the seal wants, so this diff changes the import list and nothing else — including things in that file worth changing.

What IS established, by execution

tree	probe result
clean origin/main checkout	function 'stat_owner_user_name_command' not found in scope (dag/gunbc/command_runner.dag:268)
this branch	0 blocking diagnostics

Same entry, same binary, RED before and GREEN after. Both runs also report 52 source annotation diagnostics in dag/test/manual/command_runner_local_argv_receipt_test.dag, identical on main and untouched here.

The class is closed at two — method stated so it is checkable

1. Enumerated every *_command builder defined under dag/extdeps/tools/ and dag/extdeps/posix/ — 24.
2. For every gunbc module that calls one, checked for a matching import (multi-line blocks included), a qualified module.fn(...) spelling, or a local definition.
3. Exactly one unresolved instance: this one.

#8919 stranded two sites; #9031 fixed the first; this fixes the second; there is no third.

The real defect is closure-dependence, not an unresolved name

An earlier version of this body called the symbol simply "unresolved" and predicted the required floor would refuse on it. Both were wrong, and testing them with deep-otter-200 (#9035) produced something sharper. Same clean origin/main checkout, same binary, same unchanged source file:

entry compiled	sources in closure	verdict on command_runner:268
dag/gunbc/fleet_converge_cli.dag	665	no diagnostic
an entry importing gunbc.command_runner	397	function 'stat_owner_user_name_command' not found in scope

Controlled to one variable — extdeps.tools.stat is imported by exactly three modules, one of which is gunbc.host_effect_realize. Taking the 397-source entry and adding one import of host_effect_realize, changing nothing else:

B: 397 sources                           -> diagnostic FIRES
C: B + import gunbc.host_effect_realize  -> 654 sources -> diagnostic GONE

A bare name resolves against the flat namespace of whatever modules happen to be in the closure. command_runner does not import extdeps.tools.stat; when an unrelated module drags it in, the bare call resolves. When nothing does, the same line refuses.

So compile's verdict on a module is not a property of that module — it is a property of the entry someone chose. The interpreter, which resolves through each module's own imports, rejects it either way; that is the compile/eval divergence, and it is why this can sit on a green main.

That is what this one line fixes, and it is a better reason than the one I started with: the explicit import makes command_runner's correctness independent of its closure. Today the module compiles or refuses depending on who names it.

Main is green with this in the tree

Run 32664434197 at f49886339a5: planned=10693 executed=10693 passed=10413 failed=0. This PR does not unblock anything, and an earlier title saying it did was retracted. It is a correctness repair, not an incident fix.

Attribution

Routing by ownership would send this to the #8919 lane, which is the honest owner. It was reassigned deliberately: the analysis and census already existed here, and contention was checked by path, not by name — a name-filtered PR list returns three PRs that appear to touch this file and all three touch dag/test/manual/command_runner_local_argv_receipt_test.dag, a different file with a similar name. None touches dag/gunbc/command_runner.dag.