multiprocess: claim primary listener when stale shm can't be reclaimed

Walked into this when a download manager click silently popped "An
instance of Mod Organizer is already running" with no MO2 actually
visible. State on disk: SysV shm segment from a prior MO2 still there
with nattch=0 (kernel won't reap until IPC_RMID, which only the dead
creator could call) plus the orphaned /tmp/mo-<key> socket file. The
stale-recovery path was attaching, finding no listener via
primaryAlive(), then trying to detach+create — which kept failing
because the corpse segment still occupied the key — and falling all the
way through to "re-attach as secondary". Result: the new launch flagged
itself ephemeral, forwardToPrimary() had nothing to send, and the user
got the ghost dialog.

The shm is only advisory; the unix socket listener is the real lock. If
primaryAlive() said no one's listening, we should run as primary even
when we can't reclaim the orphaned segment. Also re-probe on listen()
failure so a real race (another process becoming primary between our
probe and our listen) demotes us cleanly instead of leaving us as a
broken primary.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions