[Bug]: the SSH remote CLI launcher compiles a C# assembly on the remote host at runtime #24095

Split out of #23383, same root cause on a different surface.

src/main/ssh/ssh-remote-cli-launcher.ts installs the remote orca CLI by shelling out to PowerShell on the remote Windows host and compiling a C# source file with Microsoft.NET\\Framework64\\v4.0.30319\\csc.exe, producing an orca.exe that shadows orca.cmd.

That is the same MSIL launcher shape vendors flagged in #23383 — Trojan.MSIL.MSILHERACLES, Gen:Variant.MSILHeracles, Trojan:Win32/Wacatac.*!ml — with two aggravating factors the packaged one did not have:

1. It is compiled at runtime on the user's machine. Runtime interpreter-driven compilation is scored on its own by behavioural EDR; docs/reference/windows-edr-posture.md already lists inline Add-Type compilation as one of the behaviours that generated Defender incidents.
2. It can never be signed. The packaged launcher at least rides the SignPath chain. A binary produced on the remote host has no signature at all, so it lands as an unsigned MSIL executable in a user-writable path — the exact combination that got the packaged one quarantined.

#24094 replaces the packaged launcher with a native Rust binary and deliberately leaves this path alone, because the fix is different: a remote host has no toolchain we can rely on, so the answer is probably to ship a prebuilt native launcher over the existing relay upload rather than to compile anything on arrival. Worth checking whether the remote CLI needs a launcher binary at all, or whether the newline-safety constraint from #8374 that forced one locally also applies over SSH.

No user has reported this yet — filing it because it is the same defect and the report would otherwise arrive as another vendor name.