Duplicated sys verb implementations across linked/unlinked TUs (openUrl, unixShellCommand) -- wrong-file edits silently no-op #893

Rationale

sys.openUrl is implemented twice, in two full parallel copies that must be edited in lockstep:

• Common/source/shellsysverbs.c — case openurlfunc: (classic build)
• tests/headless_sys_verbs.c — case sysv_openurl: (headless build)

Despite living under tests/, headless_sys_verbs.c is the production implementation for frontier-cli. shellsysverbs.c is not linked into the CLI at all.

This is an active trap, not a cosmetic duplication. During #891 the exec path was first traced to shellsysverbs.c purely by reading the code; a fix landed only in that file would have compiled cleanly, passed review, and changed nothing at runtime. The miss was caught only because the red test asserted against the built binary and captured a real exec.

Current State

Build wiring (verified):

• grep shellsysverbs frontier-cli/Makefile → no matches
• tests/headless_verbs.mk:47 lists headless_sys_verbs.c in HEADLESS_VERBS_SOURCES
• frontier-cli/Makefile:240 pulls that into HEADLESS_STUBS → FRONTIER_SOURCES (:255) → link (:266)

Divergence already observed. Before #891 the two copies had drifted: the shellsysverbs.c rejection message carried a wrong Pascal length byte (\x45 declared for a 76-character string) that the headless twin did not have. Because that translation unit is not compiled by the CLI build, the headless build's static_assert never saw it. Corrected to \x4c in #891.

Same pattern, second verb. sys.unixShellCommand has the identical twin structure:

• Common/source/sysshellcall.c (:232, :324)
• tests/headless_sys_verbs.c:812 — case sysv_unixshellcommand

So this is a pattern across the sys processor, not a one-off.

Current mitigation (weak). #891 added TWIN: comments at both openUrl sites naming each other and stating which file is actually linked. That is a convention, enforced by nothing.

Desired Outcome

One implementation per verb, or a mechanism that makes silent divergence impossible.

Options worth weighing:

1. Extract the shared logic into a single translation unit compiled by both builds, with the platform/build differences behind a narrow interface. Highest value, largest change.
2. Move the headless implementations out of tests/ into a production directory. Does not remove duplication but removes the "this looks like test code" misdirection, which is the part that caused the near-miss.
3. Mechanize the lockstep check — a build- or hook-time assertion that the twin bodies stay in sync, failing loudly on drift.

Option 2 is cheap and independently worthwhile even if 1 is deferred.

Exit Criteria

• sys.openUrl has a single source of truth, or drift between the copies fails a check automatically
• Same treatment applied to sys.unixShellCommand
• The linked-vs-unlinked ambiguity is resolved or made obvious at the file's location
• A wrong-file edit cannot silently produce a no-op fix
• Full unit + integration suites green after the change

Related Context

• Found by: Headless webBrowser.openUrl should log setup URL for remote operators, not auto-launch a host GUI browser (preserve first-run onboarding intent) #891 (headless sys.openUrl GUI-browser guard), 2026-08-15
• Code: Common/source/shellsysverbs.c, tests/headless_sys_verbs.c, Common/source/sysshellcall.c, tests/headless_verbs.mk, frontier-cli/Makefile
• The TWIN: comments added by Headless webBrowser.openUrl should log setup URL for remote operators, not auto-launch a host GUI browser (preserve first-run onboarding intent) #891 are the current stopgap and should be removed once this is fixed