fix(stage1): own-check.ps1 asked the platform to OPEN the candidate, never to run it

Two platforms answered the same question wrong, and both times the platform
was not at fault.

On Linux, `& $rustCore` against a file the loader cannot start returned 0 and
printed `xdg-open: no method available for opening ...`. I read that as a
platform limit and declared the spawn-seam control not-applicable off Windows.
Windows CI then returned 0 with both streams empty, and the job's own cleanup
line terminated an orphaned NOTEPAD.

Same defect, two desktop handlers. PowerShell's call operator does not spawn a
program; it asks the platform to OPEN it, and a file that is not a runnable
image goes to whatever is registered for it. So D3.1's seam could not be
reached anywhere: the try/catch added for review defect 3 was unreachable, and
`own-check.ps1 -Engine rust` with an existing but unrunnable OWEN_RUST_CORE
exited 0 with no findings — a clean bill of health for an analysis that never
happened, which is worse than any wrong exit code.

`Invoke-CandidateProcess` starts the image with UseShellExecute = $false and
nothing redirected, so the child inherits this process's streams and its
output still arrives live. The start either succeeds or throws, and the throw
is what the existing catch was written for. Measured on Linux: exit 2 with the
"could not be started" diagnostic, where the same input previously exited 0.

The compare path was already correct — it goes through Invoke-CapturedProcess,
which has always set UseShellExecute = $false. Only the direct Rust path
opened its candidate.

Consequences for the evidence, both of which cut against my earlier reading:

The control is required on BOTH platforms and the not-applicable is gone. The
seam is answerable anywhere now, because it is a real spawn. The N/A I added
one commit ago was describing a bug in this script, not a property of Linux —
and it was reasoned from a measurement I trusted too quickly.

P07 is the mutation, and it is the shipped code: back to the call operator. It
belongs in the Windows campaign with the rest of this surface, where a
PowerShell catcher observes it natively.

Also kept: the near-miss. This control PASSED on a developer container with no
xdg-open installed, because the invocation failed there and looked exactly
like a refusal. A verdict that turns on which desktop helper happens to be
installed is not measuring the contract.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CYLNQy6tLXqsV1CbuNqsSb

Author: claude

docs/evidence/p022-stage1-windows.json

@@ -2,7 +2,7 @@
   "schema": 1,
   "comment": "GENERATED-BY-HAND definition; the RESULT beside it is recorded by scripts/mutate_campaign.py --run on a WINDOWS runner and the counts are derived from it, never typed.",
   "campaign": "p022-stage1-windows",
-  "description": "#262 Stage 1 — the surfaces whose contract only Windows can be asked about. `scripts/own-check.ps1` was driven by a CI smoke step but was absent from the adversarial control set, which is why three of its engine-contract defects survived a 16/16 campaign on the other surfaces: a campaign can only prove what some control observes. Beside it sits the Windows half of `scripts/own-check.sh`'s locator classifier, which the Linux campaign cannot reach at all — a drive-rooted path is absolute only where Windows resolves it, and a mutant of that arm is invisible on Linux whatever the runner reports. Every mutation here is a plausible MISREADING rather than a syntactic accident.",
+  "description": "#262 Stage 1 — the surfaces whose contract only Windows can be asked about. `scripts/own-check.ps1` was driven by a CI smoke step but was absent from the adversarial control set, which is why three of its engine-contract defects survived a 16/16 campaign on the other surfaces: a campaign can only prove what some control observes. Beside it sits the Windows half of `scripts/own-check.sh`'s locator classifier, which the Linux campaign cannot reach at all — a drive-rooted path is absolute only where Windows resolves it, and a mutant of that arm is invisible on Linux whatever the runner reports. It also carries the spawn seam itself: a candidate must be STARTED, never handed to the platform to open, and the two desktop handlers that proved this — notepad and xdg-open — are why the seam was unreachable on either platform until it was fixed. Every mutation here is a plausible MISREADING rather than a syntactic accident.",
   "layers": [
     {
       "id": "ps1",
@@ -97,6 +97,17 @@
       "expected_catchers": [
         "ps1::ps1-absolute-locator"
       ]
+    },
+    {
+      "id": "P07",
+      "rule": "the-candidate-is-spawned-not-opened",
+      "description": "own-check.ps1 goes back to invoking the candidate with the call operator — 'PowerShell runs it either way, why the ceremony?'. It does not run it: it asks the platform to OPEN it, so a file the loader cannot start is handed to a desktop handler (notepad on Windows, xdg-open on Linux), the run exits 0 with empty streams, and Owen reports a clean finding-free analysis of nothing",
+      "target": "scripts/own-check.ps1",
+      "pattern": "    \\$psi\\.UseShellExecute = \\$false\n    \\$proc = \\[System\\.Diagnostics\\.Process\\]::Start\\(\\$psi\\)\n    \\$proc\\.WaitForExit\\(\\)\n    return \\$proc\\.ExitCode",
+      "replacement": "    & $FilePath @ArgumentList\n    return $LASTEXITCODE",
+      "expected_catchers": [
+        "ps1::ps1-not-started-is-2"
+      ]
     }
   ]
 }

scripts/own-check.ps1

@@ -80,6 +80,43 @@ param(
 Set-StrictMode -Version Latest
 $ErrorActionPreference = "Stop"
 
+function Invoke-CandidateProcess {
+    <#
+    .SYNOPSIS
+      Run the candidate with the parent's streams, as a REAL process spawn.
+
+    .DESCRIPTION
+      PowerShell's call operator does not spawn a candidate; it asks the
+      PLATFORM to "open" it, and a file the loader cannot run is then handed to
+      whatever is registered for it. Measured on both platforms: on the Windows
+      CI runner a non-image candidate opened in NOTEPAD (the job's own cleanup
+      terminated it) and `& $rustCore` returned 0 with both streams empty; on
+      Linux the same file went to xdg-open. Either way own-check.ps1 reported a
+      clean, finding-free run having analysed nothing — a false "no findings",
+      which is worse than any exit code.
+
+      UseShellExecute = $false is what makes this a spawn: the image is started
+      or the start FAILS, with no file association anywhere in the path. The
+      failure is deliberately allowed to propagate so the caller can map it to
+      D3.1's configuration exit (2), which is the seam this whole path exists
+      to honour.
+
+      Nothing is redirected, so the child inherits this process's stdout and
+      stderr and its output streams live, exactly as the call operator's did.
+    #>
+    param(
+        [Parameter(Mandatory = $true)][string]$FilePath,
+        [Parameter(Mandatory = $true)][string[]]$ArgumentList
+    )
+    $psi = New-Object System.Diagnostics.ProcessStartInfo
+    $psi.FileName = $FilePath
+    foreach ($a in $ArgumentList) { $psi.ArgumentList.Add($a) }
+    $psi.UseShellExecute = $false
+    $proc = [System.Diagnostics.Process]::Start($psi)
+    $proc.WaitForExit()
+    return $proc.ExitCode
+}
+
 function Invoke-CapturedProcess {
     <#
     .SYNOPSIS
@@ -212,15 +249,15 @@ try {
         # The PRODUCTION Rust executable, never own-shadow-engine.
         $rustArgs = @("ownir") + $ownirArgs
         try {
-            & $rustCore @rustArgs
-            $rc = $LASTEXITCODE
+            $rc = Invoke-CandidateProcess -FilePath $rustCore -ArgumentList $rustArgs
         }
         catch {
             # D3.1's seam: the candidate never STARTED — an existing file the
             # loader will not run. That is "cannot select the candidate", so it
             # is a configuration error (2), not Owen failing internally (5).
-            # On Windows this is the only point at which a non-runnable
-            # candidate can be detected, since there is no execute bit to test.
+            # Reaching this catch is why the call above is a spawn and not the
+            # call operator: an "open" succeeds on a file that cannot run, and
+            # a seam nothing can ever arrive at is not a seam.
             [Console]::Error.WriteLine(("own-check: the candidate ``own-cli`` binary could not be started: " +
                 "'$rustCore' ($($_.Exception.Message)). Set OWEN_RUST_CORE to a runnable ``own-cli`` " +
                 "executable. Owen did not fall back to Python."))

tests/test_stage1_ps1.py

@@ -220,27 +220,25 @@ def control_not_started_is_2(sample: Path, tmp: Path) -> None:
 
     This is the case the CI smoke step could not reach: it used a NONEXISTENT
     path, which `Test-Path` rejects long before any spawn.
+
+    It took two wrong answers to get here, and both were the production code
+    rather than the platform. I first declared this control Linux-N/A because
+    PowerShell there returned 0 and printed `xdg-open: no method available for
+    opening ...`; Windows CI then returned 0 with both streams empty, and the
+    job's own cleanup terminated an orphaned NOTEPAD. Same defect, two desktop
+    handlers: own-check.ps1 was ASKING THE PLATFORM TO OPEN the candidate
+    rather than spawning it, so the seam could not be reached anywhere and
+    Owen reported a clean, finding-free run having analysed nothing. With a
+    real spawn (UseShellExecute = $false) the start either succeeds or throws,
+    and the contract is answerable on both platforms — so this control is
+    required on both, and the N/A is gone.
+
+    The near-miss is worth keeping: on a developer container with no xdg-open
+    installed, this control PASSED, because the invocation failed and looked
+    exactly like a refusal. A verdict that turns on which desktop helper
+    happens to be installed is not measuring the contract.
     """
     check = "ps1-not-started-is-2"
-    if os.name != "nt":
-        # Measured on a Linux runner: PowerShell there does not refuse a
-        # non-executable file, it hands it to the DESKTOP OPENER — the run
-        # exits 0 with `xdg-open: no method available for opening ...`. So
-        # "the loader will not start this image" is not a state Linux can be
-        # asked about; it answers a different question and answers it
-        # successfully.
-        #
-        # Worth recording why this was nearly missed: the control PASSED on a
-        # developer container, for the wrong reason — no xdg-open was
-        # installed there, so the invocation failed and looked like a refusal.
-        # A control whose verdict depends on whether a desktop helper happens
-        # to be present is not measuring the contract. This is exactly the
-        # case the Windows-native mutation leg exists for.
-        not_applicable(check, "PowerShell on Linux routes a non-executable file to the desktop "
-                              "opener instead of refusing it, so the spawn seam cannot be posed "
-                              "here; it is required on Windows, where the ps1 mutation campaign "
-                              "runs")
-        return
     unstartable = tmp / "not-a-program.txt"
     unstartable.write_text("this is text, not an executable image\n", encoding="utf-8")