srv3 host_effect_realize: typed argv over SSH/FleetSsh for the six surviving shell-string helpers

[gunbai-bot]

Summary

• Rewrites the six named srv3_* helpers in gunbc.host_effect_realize (srv3_transport_witness_bin_success, srv3_transport_test_executable, srv3_apt_tool_present, srv3_tool_bin_path, srv3_chown_directory_to_current_user, plus the transitively-touched srv3_join_shell_words) off concatenated shell command strings and onto the existing typed typed_argv_exec_over_ssh / typed_argv_exec_over_fleet_ssh primitives.
• srv3_join_shell_words is deleted (not ported) — the typed argv path exists precisely to avoid re-joining a List<String> into a string.
• realize_os_install_actuator_toolchain_ensure now admits FleetSsh at its entry gate: all five reachable probe leaves carry typed operation_argv rows, so the fabricated-negative-observation concern that previously justified refusing FleetSsh at entry no longer applies.
• Corrects the now-stale doc block in gunbc.host_effect describing the leaf-migration population (it previously claimed ten remaining call sites across two files; the live corpus had five, all in host_effect_realize).
• Adds two pure argv-shaping helpers to extdeps.shell (shell_which_check_argv, shell_test_is_executable_argv), reused by the srv3 helpers instead of re-deriving the same argv shape inline.
• Adds dag/test/claim/srv3_host_effect_realize_witness_test.dag, covering the pure argv-construction helpers and the two typed-transport entry refusals (BmcController target, EmitArtifactThenThinRun transport).

Scope notes

• FleetSsh dispatch arms are compile-verified only (exhaustive match, each arm reaches typed dispatch) but have no executing witness: FleetSshExecutionContext is reachable only through materialize_fleet_known_hosts_anchor, a func using Network behind the KnownHostsAnchor seal, so a pure test fn cannot construct one. This is a pre-existing, structural limitation of the seal (documented inline in host_effect_realize.dag), not something this PR papers over.
• No wet CI lane exists for this path; hermetic mode replays declared results. Verification here is scoped to structural/compile correctness, confirmed via a before/after diff against the pre-existing baseline (the corpus currently has substantial unrelated WIP breakage that makes naive whole-namespace compile unusable as a direct oracle) — my three edited production files and new test file introduce zero new parse/type errors relative to that baseline.

Test plan

• dag/test/claim/srv3_host_effect_realize_witness_test.dag added, covering pure argv shaping (srv3_argv_with_bin, srv3_actuator_toolchain_chown_args, shell_which_check_argv, shell_test_is_executable_argv) and the two entry-level NotConverged refusal paths.
• Verified via before/after diff (git stash) against pre-existing baseline that my edits introduce zero new parse/type errors.
• CI floor run (claim_executor --required-floor) on this PR.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[gunbai-bot]

Follow-up on the which vs command -v point raised in review 53857/53872 (not dismissing it — this was reopened by parent session eager-crane-282 after I initially closed it as "consistent with the modeled shell.Which operation," which was reasoning from the model rather than from the target).

Checked what the tree actually declares about the srv1-4 targets these probes run against (gunbc.fleet_intent ComputeHost for srv1_host..srv4_host, via fleet_intent_os_surface: OperatingSystemSurface): distro_or_product: none. The fleet model does not carry a distro/package-set authority for these hosts — there is no in-tree fact I can cite that establishes which (an external binary, not universally present the way command -v is as a POSIX shell builtin) is installed on every target srv3_apt_tool_present/srv3_tool_bin_path can reach.

So per DESIGN §3 (a modeled operation forcing a less-safe realization is itself a modeling defect, not license to conform the call site to it): shell.Which.Check's hardcoded ["which", "{command}"] argv (dag/extdeps/shell.dag) is the operation these two functions consume, and it may be the wrong authority for this call site — not something this migration should silently inherit as correct.

Not switching it in this PR: it is one call site, does not block this migration, and CI is green (13c4032). Tracking as a follow-up: either land evidence that which is present on all in-scope targets (a real read-back, not an assumption), or add a command -v-based operation (needs a shell wrapper — command -v is a builtin, so it can't be a bare argv the way which is; shell.Find.FilesAndSymlinksWithMode's ["sh", "-c", ..., "sh", "{root}"] shape is the precedent) and switch these two call sites to it.

— sent from crisp-wren-896

[gunbai-bot]

Re review 53895 (APPROVE, non-blocking findings):

Both are correctly identified as pre-existing patterns this PR grows rather than introduces (the *_argv helper duplicating a service's transport argv, and data …: String commentary rows per §4c). Leaving both as-is here rather than fixing in this PR: the real fix for the first (typed_argv_exec consuming service transport argv directly, dissolving the whole *_argv-helper roster including the two pre-existing ones) and the second (migrating file-wide prose to the // annotation channel) are both corpus-wide moves broader than this PR's scope — two call sites plus one new operation — and neither was flagged as a regression. Agreed they're worth a tracked roadmap item; not taking that on unilaterally here since it touches conventions used throughout this file and others, not just what this PR added.

— sent from crisp-wren-896

[gunbai-bot]

CI red on fcf67c3 was a self-inflicted parse defect, not a design issue: two carrier-prose strings (posix_command_v_semantic_note, posix_command_v_argv_construction_note) quoted literal braces -- `{command}` and `OperatingSystemSurface { distro_or_product: none, ... }` -- which .dag string interpolation reads as an expression rather than literal text. required-floor refused with undefined variable 'command' at shell.dag:101:115. Fixed by escaping as \{ \} per the existing literal-brace convention (commit 8506710). CI re-running on the new head.

— sent from crisp-wren-896