SDK close can hang indefinitely when a login child ignores SIGTERM

[GautamSharma99]

Summary

Cancellation sends one signal and then waits without a deadline:

• CodexLoginHandle.cancel()
• CodexSecurity.close()
• CLI child signal forwarding

cancel() sends SIGTERM once. close() then awaits every login handle with Promise.allSettled and has no timeout or escalation path.

A child can ignore SIGTERM. A descendant can also inherit stdout/stderr and keep the pipes open after the immediate child exits. Either case can leave SDK shutdown waiting indefinitely. The interactive-login implementation has a Windows-only pipe fallback, but no equivalent POSIX deadline or forced termination.

Why this matters

An application embedding the SDK can become permanently stuck during cleanup. CLI commands using the same one-signal pattern may also fail to return after cancellation.

Expected behavior

Cancellation should allow a short cooperative grace period, then guarantee that child-process resources settle.

Suggested direction

• Record cancellation and send the normal termination signal.
• After a bounded grace period, escalate to SIGKILL or the platform-appropriate process-tree termination mechanism.
• Explicitly destroy remaining pipes before settling completion.
• Ensure timers are cleared after normal exit.
• Test with a child that ignores SIGTERM and a descendant that retains inherited pipes.

The current tests use children that cooperate with SIGTERM, so this path is not exercised.

This is separate from #44: that issue concerns a canceled scan remaining marked RUNNING; this issue concerns the cancellation operation itself never settling.

Found by static audit of upstream main at 9c7634b.