Spike: feasibility of a Windows + Podman end-to-end CI lane

## Context

Podman parity is now supported on Linux (#30, #237, #238): a required `Test (Podman)` lane runs the integration suite against rootless podman on an `ubuntu` runner. The **Windows** CI lane is still the `dev-fast` nextest profile — it excludes Docker/smoke/testcontainers and exercises only platform-agnostic logic (no container runtime).

This is a **timeboxed spike** to answer one question: can we stand up a real `up → exec → down` end-to-end on a **Windows** runner using podman, to validate deacon's Windows **host-side** container path (mount path translation, spawning `podman.exe`, line endings) that `dev-fast` can't reach?

## Why it's not a one-line change

1. **Podman on Windows is a Linux VM, not native.** `podman` on Windows is `podman machine` over WSL2 — a Fedora-based Linux VM running *Linux* containers. So this validates "Windows host driving a Linux backend," not Windows containers. That's still valuable (it exercises the Windows host-side code), but it's a different goal than the Linux lane.
2. **GitHub-hosted `windows-latest` is the likely blocker.** `podman machine` needs WSL2, which needs nested virtualization. GitHub-hosted Windows runners have historically not provided that reliably. May require a self-hosted or specially-configured runner.
3. **Known Windows gaps will surface first.** Host-path mount semantics and host-hook (`initializeCommand`) execution are tracked Windows follow-ups, and much of the container-exec / port-forward code is `#[cfg(unix)]`-gated. An e2e will hit these before it tells us anything about podman parity.

## Spike tasks (timeboxed)

- [x] Determine whether GitHub-hosted `windows-latest` can install + start `podman machine` (WSL2 / nested virtualization). Capture the failure mode if not. ✅ **Yes** — Server 2025 + WSL 2.7.3; machine boots ([run](https://github.com/get2knowio/deacon/actions/runs/27489646816), [findings](https://github.com/get2knowio/deacon/issues/239#issuecomment-4700837617)).
- [x] If viable: stand up a minimal `deacon up → exec → down` against a small Linux image (e.g. `docker.io/library/alpine`) with `DEACON_CONTAINER_RUNTIME=podman` on Windows. ✅ `exec` returned the marker with exit 0; Windows workspace path translated to `/workspaces/spike-ws`.
- [x] Enumerate which Windows host-side paths it actually exercises (mount source path conversion, `podman.exe` invocation) vs. which stay `#[cfg(unix)]`-gated. ✅ See findings: process spawn + runtime selection, default workspace bind-mount translation, env probe, exec. Not exercised: lifecycle/features/builds/port-forward (`#[cfg(unix)]`) / `initializeCommand`.
- [x] Decide: dedicated Windows+podman lane (and whether it can be required), keep it `continue-on-error`/manual, or defer with a written rationale. ✅ **Decided:** added a non-required **nightly** smoke lane (`.github/workflows/windows-podman-smoke.yml`, #242) — gather reliability data, then revisit promotion to required (the #236→#237 playbook).

## Out of scope

- Windows *containers* (deacon targets Linux dev containers).
- Closing the underlying Windows gaps (host-path mounts, `initializeCommand`) — those are separate; this spike only scopes whether/how to test them under podman.

## References
- #30 (Podman parity), #237 (burn-down → required lane), #238 (1.1 polish)
- CLAUDE.md "Cross-Platform / Windows Notes" (the `dev-fast`-on-windows rationale and tracked Windows follow-ups)