TUI side-copy cleanup can preserve stale leases after PID reuse

[me2seeks]

What happened

PR #3759 identifies the TUI process that owns a temporary Session-copy cleanup lease as tui:<pid>.

After an unclean TUI exit, the operating system can reuse that PID for an unrelated process. A later TUI then treats the stale owner as active and skips recovery, leaving the temporary Session copy on the Runtime Host.

Expected behavior: cleanup ownership should be tied to one process incarnation. A live TUI must never be reaped, while copies owned by an exited TUI must remain recoverable even after PID reuse.

How to reproduce

1. Create a side conversation with the implementation from feat(tui): add side conversation lifecycle #3759.
2. Terminate the owning TUI before its cleanup completes.
3. Allow the recorded PID to be reused by another process.
4. Start another TUI and run Session-copy recovery.
5. Observe that the stale lease is skipped because the PID is currently alive.

PID reuse is timing-dependent in production, but the ownership collision can be reproduced deterministically by presenting two process incarnations with the same PID.

Environment

• Maka commit: 5cd23d688
• OS: affects supported desktop platforms
• Surface: TUI / Runtime Host
• Node.js version used for source validation: v26.3.0

Logs, screenshots, or additional context

This tracks the non-blocking P3 follow-up identified during review of #3759.

The recovery identity should use an OS-held process-lifetime primitive while preserving PID-only records written by older clients.

[me2seeks]

I'm working on this.