wslc: assert Pid > 0 in DockerExecProcessControl::SetPid

[benhillis]

Summary

Defense-in-depth follow-up to #40550. Adds WI_ASSERT(Pid > 0) in DockerExecProcessControl::SetPid so any future caller that bypasses the state.Pid > 0 filter in the exec polling loop is caught immediately in Debug builds.

Background

#40550 fixed a hang in WSLCContainerImpl::Exec where Docker's transient {Running=true, Pid=0} response (seen on fast runc failures, e.g. -u root:badgid) was treated as a valid running process. The polling loop now filters state.Pid > 0 before calling SetPid, so production behavior is correct.

This PR adds a hard assertion at the sink so the contract is enforced at the lowest level. Without it, a future caller refactor that drops the Pid > 0 check would silently hang WSLCProcess::Wait forever, because Docker never emits exec_die for a process that never spawned.

Change

void DockerExecProcessControl::SetPid(int Pid)
{
    std::lock_guard lock{m_lock};

    // Pid must be a real (forked) process. Docker reports Pid=0 in the brief
    // window between StartExec returning and runc actually forking the user
    // process; treating 0 as a valid PID causes the exec wait to hang forever
    // because Docker never emits exec_die for a process that never spawned
    // (see PR #40550). Callers must filter Pid > 0 themselves.
    WI_ASSERT(Pid > 0);
    WI_ASSERT(!m_pid.has_value());

    m_pid = Pid;
}

Suggested by @OneBlue in the #40550 review.

[Copilot]

Pull request overview

Adds a debug-only contract check in the wslc Docker exec process-control path to ensure an exec PID is always a real, forked process ID, preventing future regressions of the previously-fixed “Pid=0 treated as running” hang scenario.

Changes:

• Add WI_ASSERT(Pid > 0) to DockerExecProcessControl::SetPid to enforce the caller contract in Debug builds.
• Add an explanatory comment documenting Docker’s transient Pid=0 behavior and the hang failure mode.