Document and stabilise the live session registry (~/.claude/sessions/<pid>.json), and expose it to hooks

What I'm asking for
Please make the live session registry a documented, supported interface instead of an implementation detail, and give hooks and the status line a supported way to read it.

Why I need it
I run Claude Code in tmux, usually with several sessions open on one machine, and I regularly walk away from them. Twice now I've had two sessions pointed at the same directory by accident, and they overwrote each other's notes. I've been building a small hook layer to deal with it: a per-directory lease, a warning that names the other live sessions (their PIDs and working directories), and a refusal to overwrite shared files from the second session. Everything useful for that is already in ~/.claude/sessions/<pid>.json, but nothing documents it, so I can't responsibly depend on it.

What I found (macOS, versions 2.1.291 to 2.1.293)
One file per live process, named by PID. Fields I saw: pid, sessionId, cwd, startedAt, procStart, version, kind (interactive or bg), entrypoint, status (busy, idle, shell), statusUpdatedAt, updatedAt, name, nameSource, tmux (the pane id), messagingSocketPath, peerProtocol, peerFeatures. Every PID in the directory was alive when I checked. It's exactly the data a same-directory check needs, and procStart is what lets a tool tell a reused PID from the original process.

Specifically

1. Document it: location, schema, which fields are stable, and a version field so tools can tell when it changes.
2. Write it atomically and clean it up. #96438 reports a registry file with a stray trailing }, so tools are already parsing it. Say what happens to the file when a session crashes or is killed, and whether procStart is the supported way to detect PID reuse.
3. Give hooks and the status line a supported route to it: for example an environment variable or hook input field with the registry directory, or claude sessions --json. Today a hook gets CLAUDE_CODE_MESSAGING_SOCKET but cannot list its peers (see also #94620 and #97220).
4. Say which neighbouring files are credentials. There is a *.key file next to each registry entry. I did not open them, but anyone who parses that directory needs to know not to.
5. Consider a first-party warning when a second live session starts in a directory where one is already running. Several of you are already tracking the symptoms (#69364, #76727, #88862, #98950); the registry is the piece all of them need.

What I'm not asking for
Automatic merging of two sessions' edits. Arbitration (warn, ask, or follow-only) is enough. Peer messaging is already documented; the on-disk registry is the part that isn't.