#3248 Windows: workflow run --input does not honour \@ escape in k=v value

Tested on Windows Server 2022 with swamp 20261011.153055.0. The test passes --input message=@notafile via Deno.Command (no shell involved, the backslash reaches swamp directly). On Linux the workflow run succeeds and the resolved value contains @notafile (the @ escape produces a literal @). On Windows the workflow run succeeds (exit 0) but the model stdout is empty - the value was not passed through to the step. The test asserts assertStringIncludes(stdout, "@notafile") which fails because stdout is empty. The @ file-reference and @ escape are swamp own conventions implemented in the CLI argument parser, not shell behaviour, so they should work identically on Windows.

Triage analysis: the backslash-at escape is honoured on Windows. The empty stdout comes from PowerShell, not from swamp's input parser.

Why: the test workflow cel-workflow-inputs runs the shell-consumer command/shell model with run set to echo ${{ inputs.message }}, which renders as echo @notafile. On Windows, command/shell runs through powershell.exe -NoProfile -Command (src/domain/models/command/shell/shell_strategy.ts). In PowerShell argument mode, @name is the splatting operator: @notafile splats the undefined variable notafile, so echo receives zero arguments and prints an empty line. POSIX sh gives the at sign no meaning, which is why Linux passes.

The observed exit code rules out the other explanations:

• If the backslash were lost in transit, the value would be @notafile, swamp would try to read it as a file, and the run would fail with "Input file not found" and a non-zero exit. The observed exit was 0.
• If the backslash were doubled or mangled, neither parser branch would match and echo would print the mangled text, so stdout would not be empty.
• If the escape is honoured, the value is @notafile, PowerShell splats it to nothing, and the run gives empty stdout with exit 0. This is the only case that matches what was observed.

Please confirm on the Windows runner with either check:

1. After a failing run, in the test repo: swamp data get shell-consumer result --json. The shell model records the command it ran in the command field. If it reads echo @notafile, the value reached the step intact.
2. Directly: powershell -NoProfile -Command "echo @notafile". This should print nothing, while powershell -NoProfile -Command "echo '@notafile'" prints the literal.

If confirmed, the fix belongs in swamp-uat in tests/cli/e2e/workflow_inputs_test.ts test 12, not in swamp. Use a dedicated workflow fixture that single-quotes the interpolated value (echo '${{ inputs.message }}'), or assert on the resolved workflow input instead of shell stdout. swamp passes interpolated values to the shell unquoted on every platform, and it should not quote or rewrite user shell commands.

If command shows the value is missing (echo alone), reply here with the output and we will re-triage as a swamp bug.

Confirmed on Windows Server 2022. echo @notafile produces empty output (PowerShell splatting). echo with single-quoted @notafile produces the literal value. The triage is correct: this is a test infra issue. The test workflow fixture uses echo ${{ inputs.message }} which passes the value unquoted to PowerShell. The fix is in the test fixture, not the product. Will create a Windows variant of cel-workflow-inputs that single-quotes the interpolated value.

Closing as not a product bug. The @ escape is honoured correctly. The empty stdout is PowerShell interpreting @notafile as a splatting operator. Fix belongs in swamp-uat test fixture.