fix(code-runtime-python): treat an absent start-time reading as reaped, not recycled

The PID-reuse guard refused to signal whenever the current reading differed
from the one taken at spawn, including when it was ABSENT. On Linux a reaped
leader has no /proc/<pid>/stat, so every teardown after the leader exited
skipped SIGTERM/SIGKILL while the group it led still held survivors -- the
exact case the process-group teardown exists to reap. Three same-group survivor
tests went red on the coverage lane; they pass on Darwin because the reader
always returns undefined there, leaving the guard inert.

Only a present-and-different reading now blocks the signal. Verified on the
self-hosted Linux box: a reaped leader with live survivors allows the signal, a
pid whose start time differs still blocks it, and a live matching process is
signalled.

packages/code-runtime/code-runtime-python/tests/runtime.spec.ts

@@ -399,7 +399,13 @@ describe('PythonCodeRuntime — process identity', () => {
       expect(own).toBeDefined()
       expect(readProcessStart(process.pid)).toBe(own)
       // Pid 0 is never a readable /proc entry, so the guard degrades to
-      // undefined rather than throwing on a teardown path.
+      // undefined rather than throwing on a teardown path. This is also the
+      // reading a REAPED leader produces -- its /proc entry is gone while the
+      // group it led can still hold survivors -- so `undefined` must NOT be
+      // treated as an identity mismatch. Reading it as one refused the SIGKILL
+      // that the same-group survivor tests depend on, which is why they went red
+      // on Linux while passing on Darwin (where the reader always returns
+      // undefined and the guard is inert).
       expect(readProcessStart(0)).toBeUndefined()
     } else {
       // Darwin has no /proc: the reader reports undefined, and `killGroup` then