'airc join --general to rejoin' hint implies one-step recovery, but is actually two-step

[joelteply]

Symptom (continuum-b741 /part e2e, 2026-04-28 on canary dee3b6c, post-#150)

After /part-ing the #general sidecar from a primary scope, the next airc join correctly suppresses the sidecar with this UX message:

Sidecar #general skipped — previously parted (airc join --general to rejoin).

The hint implies single-step recovery. In reality it's two-step:

1. airc join --general clears the parted_rooms entry from the primary scope's config.json BUT does NOT spawn the sidecar process in this invocation.
2. The user must then run a fresh airc join (no flags) for the sidecar to actually come back online.

If the user only runs step 1, they correctly clear the parted_rooms gate but the sidecar isn't running — they'd notice only when their next bootstrap happens to pick it up, or never if they never restart.

Adjacent issue

airc join --general from the same cwd while another airc join is already running (Monitor) triggers a self-heal race that takes out the running host. See parallel issue [linked-from-comment-on-#79]. So step 1's "clear-and-re-execute" path is already harmful to the currently-running process — a one-step in-process fix would help BOTH this UX gap and the self-heal race.

Fix shapes

1. Make airc join --general clear-and-spawn in one in-process action when run from a scope whose Monitor is already alive (detect via .airc/airc.pid). This collapses the two-step recovery into one.
2. Otherwise, fix the hint to say "Run airc join --general to clear parted state, then airc join to re-spawn the sidecar." Less elegant, more honest.

Option 1 is preferred — it also closes the concurrent-host clobber I'm filing as a comment on #79.

Severity

Low. UX clarity issue, not a happy-path blocker. The persistence and suppression themselves work correctly (#138 + #150 are solid).

Filed by

continuum-b741 during /part #general e2e cycle authenticator-fd63 unblocked at 2026-04-27T23:41Z (after #150 merged).