Pinned, restart-stable session identity for addressing workers across relaunches

[iRonin]

Problem

There is no stable, restart-surviving handle for addressing a logical worker.

The two identifiers a peer can target are both tied to a single process lifetime:

• The fallback alias subagent-chat-<id> is derived from the pi session id, so a fresh session (quit + relaunch, not resume) gets a new alias. A parent that cached subagent-chat-019eb2da then gets Session not found after the worker restarts.
• The broker session id (SessionInfo.id) is a randomUUID() assigned per connect (broker.ts), so it changes on every reconnect.

The only stable handle today is a user-chosen /name, but that must be re-applied on every fresh start, and (until #11) didn't even propagate reliably. For an orchestration setup where a supervisor relaunches workers, there's no way to say "this is the same DCA-worker as before" automatically.

Proposal (seeking direction before coding)

Let a session pin its advertised presence name so a relaunched worker re-advertises the same address with no manual /name.

There's already a related primitive — PI_SUBAGENT_INTERCOM_SESSION_NAME — but it only feeds contact_supervisor routing metadata; it does not set the session's advertised presence name. Options:

1. Env var (e.g. PI_INTERCOM_SESSION_NAME) read at session_start; when set, resolveIntercomPresenceName() returns it instead of pi.getSessionName()/the fallback. A launcher/orchestrator can pin a stable name per worker role.
2. Config field in ~/.pi/agent/intercom/config.json (sessionName), same effect, for non-launcher setups.
3. Both (env wins over config wins over /name/fallback).

This composes with #11 (the pinned name still needs to propagate promptly) and is adjacent to #35 (routing by a stable identifier rather than a possibly-duplicate display name) — a pinned name is stable but author-controlled for uniqueness.

Questions

• Do you prefer env, config, or both for pinning?
• Should a pinned name take precedence over a later interactive /name, or should /name override the pin for the rest of the session?
• Any concern with this vs. the direction in contact_supervisor should route by stable session ID, not duplicate names #35 (stable id routing)? They seem complementary (pin gives a stable name; contact_supervisor should route by stable session ID, not duplicate names #35 makes routing robust to duplicates), but want your call before sending a PR.

Happy to implement once you point at the shape you'd accept.

[iRonin]

Opened #40 implementing the stable-id half of this: the broker accepts a caller-supplied sessionId (the pi session id) and uses it as the routing identity, so it survives reconnects (fixes the "Session not found" race when a peer's resolved name→id goes stale after the target reconnects). That's complementary to #35/#37 (which route by the broker id but leave it per-connect random). The pinned-name question from this issue is still open — happy to follow your steer on env vs config for that part.

[nicobailon]

#54 now stabilizes the broker session ID across reconnects, which covers the reconnect-race part of this area. I’m leaving this open because pinned restart-stable worker identity across fresh relaunches is still a broader product/API question.