Expose which session a client is attached to (client pid in `zmx list`, or `zmx whoami`)

[chancez]

Given the process id of a zmx attach client, there is no supported way to ask which session that client is currently displaying.

zmx list reports clients=1 as a count only, never an identity, and zmx get returns just labels. The client's own argv is not reliable either, because of the session-switch behavior discussed in #151 and #167: after a switch, argv still names the session the client was launched with, while it is connected to a different one.

client pid 11533   argv:   zmx attach ev.host
                   socket: /tmp/zmx-501/ev.other

The only approach I found is matching unix socket peer addresses with lsof, which needs two invocations because the client holds an unnamed peer address and the daemon side holds the path:

lsof -p "$PID" -a -U     # -> ->0xb831feaf3cbe7349
lsof -U | grep "$PEER"   # -> /tmp/zmx-501/ev.other

That depends on undocumented socket layout, costs around 50ms, and is easy to get subtly wrong: while working on this I had a stale peer address resolve to the wrong session, which is exactly the kind of mistake that becomes destructive in the use case below.

Why I need it

I run kitty with each window's process being zmx attach <name>, so that quitting kitty leaves the sessions running and restoring the saved layout reattaches to them. Two things in that integration need to map a window back to a session:

1. Closing a window should kill its session, otherwise closing a tab silently orphans one. Resolving the name from launch arguments killed the wrong session for me after a switch, destroying the work running in it.

2. Opening a new split should inherit the session's current directory. That is a two step lookup: window to session name, then session name to cwd. The second step is Let ghostty see cwd of newly attached session #160, and it needs the first step to even begin.

Both steps are currently lsof calls against undocumented internals.

What would help

Anything that exposes the mapping, for example:

• a client_pids= field in zmx list
• a zmx whoami [--pid N] that prints the session name for a client

Combined with the JSON output in #220 this would make terminal integrations straightforward. Worth noting that if OSC 7 forwarding lands for #160, the second lookup goes away on its own, and this would be the only remaining hole.

[neurosnap]

My gut reaction is to replace clients=N with a list of pids in zmx list.

[chancez]

Yah that feels natural to me.