bug(debug): a bundle picks the proxy run by conversation key, so it can bundle another pane's resumed run #1405

Found by review a of #1399. This predates #1399.

Sequence (both providers)

1. Pane p1 starts a fresh conversation T, and its proxy run is C/shell-p1/R1. p1 exits but stays visible.
2. Another pane p2 resumes T and writes C/resume-T/R2.
3. Save Debug Logs on p1.

The bundle asks for resume-T (because p1's providerSessionId is T), gets match: 'exact', and bundles R2, which is p2's traffic and prompt. The manifest names R2 honestly, but the bundle says sessionId: p1.

Why

• The reader's "exact" is a segment-name match. proxyEventsReader matches a segment directory by name and takes its newest run. That proves neither pane nor process provenance.
• resume-<id> names a conversation, not a pane. Only shell-<sessionId> is pane-keyed.
• session-meta.json cannot tell them apart. It holds {createdAt, cwd, sessionKey} and no owning pane.

Direction

Record the launch-time proxy session key, resume-X or shell-Y, as each process actually chose it:

• have the spawn result report it, and persist it on the pane's meta;
• have the bundle ask for exactly that key.

Optionally also stamp the owning local session id into session-meta.json (the Claude package and Codex's allocateProxyEventsFile), so the reader can verify ownership.

It touches sessionManager spawn, both provider sessions, session meta and saveDebugBundle. A two-pane regression test belongs at the assembler/reader seam.