phase9: add the worker-identification procedure to the plan

With four fresh sessions in one repository the coordinator must be able to tell
which peers are its workers without assuming: list the sessions in this cwd
excluding itself, probe each, recruit the responders up to three, never charter a
session that has not answered, and record the recruited ids in the ledger so a
later cycle or a replacement coordinator can tell who is who. This also covers the
case where an extra session (a planning session left open) is live in the repo.

phase-ends/Phase9_PLAN.md

@@ -50,6 +50,20 @@ Phase 9 has the infrastructure ready and three full-time matchers, so 200–300
 the stretch. The plan therefore stages the target (see the checkpoints) so a shortfall is visible early, and
 defines explicit stop conditions instead of letting the run spin.
 
+## Identifying the workers
+
+The coordinator must know which peers are its workers, and it must not assume. The procedure:
+
+1. `intercom({action:"list"})` and take every session whose cwd is this repository, **excluding itself**.
+2. Send each one the capability probe from the protocol. A peer that answers is a candidate worker; a peer that
+   does not answer within one `CHECKIN` is recorded as unusable and left alone.
+3. With the intended four sessions running (one coordinator, three workers) the set is unambiguous. If more
+   sessions are live in this repository — for example a planning session left open — the coordinator uses the
+   responders in the order they answer, up to three, and records which sessions it recruited and which it left
+   alone. **Never charter a session that has not answered the probe.**
+4. Record the recruited session ids in the ledger at the top of `CURRENT_PHASE.md`, so a later cycle (or a
+   replacement coordinator) can tell who is who.
+
 ## Carried context (do not re-derive; verify before relying on)
 
 - Validated USA `SCUS_946.40;1`: 1,886,208 bytes, SHA-1 `e173426c157384ebf1b6caf8c6fea18a85a14af9`.