cli: create sessions by attaching, to dodge the phantom-client bug

Reported symptom: a pane titled "MY FOCUS AND:" in a fresh sl0ppi session.

That is zellij's multi-user indicator. A session created with
`attach --create-background` keeps one client in its connected set forever, so
`connected_clients.len() > 1` and every pane frame renders its multi-user form
with one anonymous colour block. sl0ppi created every session that way, so every
sl0ppi session looked like someone else was in it.

Isolated by comparison rather than by reading:

  created with attach --create-background   marker on the FIRST attach, and every one after
  created by an ordinary attach that dies   no marker, ever

Ruled out by measurement: not the CLI-action clients (15 actions with no attach
leaves nothing behind), and not the creating client exiting too early (making it
wait for a server ack -- 94ms, server answered -- changed nothing; that
experiment was reverted rather than shipped with a comment claiming a fix it did
not deliver). The client-id change did not cause this either: it only made it
visible, because recycled ids used to hand the phantom's id straight to the next
client that attached.

So: when `sl0ppi` has a terminal it now creates the session by ATTACHING to it
(`--layout X attach --create NAME`) instead of creating it in the background and
attaching second. That is the path with no leak, and it is one process instead
of two. Headless `up` keeps the background path, where no one is looking at a
pane frame.

This is a workaround. The fork bug is recorded in docs/roadmap.md with what has
been ruled out and where to instrument next, and it still affects anyone calling
`zellij attach -b` directly.

Verified on the test box under a real pty: no marker on creation or on any later
attach, both project tabs present, agents still staged
(purpose='agent:main' held=true cmd='pi').

1 files changed, 33 insertions, 0 deletions

diff --git a/docs/roadmap.md b/docs/roadmap.md
index 6aa1059..d05e4e7 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -160,6 +160,39 @@ Worth revisiting: `send_to_client` silently returns `Ok(())` for an unknown
 client id. An unknown id is a caller bug, and swallowing it is what made this
 take a day to find instead of a minute.
 
+## Known issue: `attach --create-background` leaves a phantom client
+
+A session created with `attach --create-background` keeps one client in its
+connected set for the rest of its life. Nothing renders that client directly,
+but it makes `connected_clients.len() > 1`, so `multiple_users_exist_in_session`
+is true and **every pane frame shows its multi-user form** — `MY FOCUS AND:`
+followed by one anonymous colour block. It looks like a stranger is in your
+session.
+
+Isolated by comparison, on the test box:
+
+| session created by | marker on first attach |
+|---|---|
+| `attach --create-background` | **yes**, and on every later attach |
+| ordinary `attach --create` whose client later dies | no |
+
+Exactly one phantom, always the session's first client; it does not accumulate.
+Not caused by the client-id change — that only made it *visible*, since recycled
+ids used to hand the phantom's id straight to the next attaching client.
+
+Things ruled out by measurement: it is not the CLI-action clients (a session with
+15 actions and no attach shows nothing extra), and it is not a race with the
+creating client exiting too early (making that client wait for a server ack
+before exiting — verified 94ms, server answered — changes nothing, so that
+experiment was reverted rather than shipped).
+
+**Worked around, not fixed.** `sl0ppi up` now creates the session by *attaching*
+to it whenever it has a terminal, which is the path that does not leak; the
+background path remains for headless use, where no one is looking at a frame.
+The fork bug is still there for anyone calling `zellij attach -b`, and the next
+step is to instrument `ScreenInstruction::RemoveClient` on a debug build to find
+why the removal never reaches `screen.connected_clients`.
+
 ## Standing risks
 
 **`sl0ppij/target` is a symlink to `~/lol/zellij/target`.** Introduced when the