Agent tool background-dispatch becomes permanently unresumable after a session/context rollover, despite transcript existing on disk

### Summary
When the `Agent` tool is dispatched with `run_in_background: true` and the parent conversation undergoes a session rollover (e.g. context compaction, producing a new session ID), the background agent's completion notification never arrives, and `SendMessage` cannot resume it — even though the agent completed successfully and its full transcript exists on disk exactly where expected.

### Environment
- Claude Code version: `2.1.270` (from transcript metadata)
- Entrypoint: `sdk-ts`
- Platform: Linux

### Steps to reproduce
1. In a session (call it session A, ID `173d72f3-...`), dispatch a background `Agent` (`run_in_background: true`). Note the returned `agentId`.
2. Let the conversation continue long enough to trigger a session rollover — in this case, context compaction produced a new session ID (`67a929`, visible afterward via `ListAgents`).
3. Wait for the agent to finish. No `` arrives in the (now-rolled-over) session.
4. Attempt `SendMessage({ to: "" })` to resume/read the result.

### Observed behavior
`SendMessage` returns:
```
{"success":false,"message":"Agent \"\" could not be resumed: No transcript found for agent ID: . If you read this id in a message from another Claude Code process ..."}
```

But the transcript **does exist** and is complete:
```
/home//.claude/projects//173d72f3-.../subagents/agent-.jsonl (218KB)
```
— ending cleanly in a normal finished assistant turn, timestamped after the dispatch. The agent did its job; only the resume/notification path failed.

### Root cause (as far as I can tell from the outside)
The agent's transcript is stored under the **session that launched it** (`173d72f3-...`). `SendMessage`'s resume logic appears to look for the agent only within the *current* session's own subagent directory. Once the parent conversation rolls over to a new session ID (compaction), the current session no longer "owns" that subagent directory, so the agent becomes unreachable via `SendMessage` — permanently — even though nothing was lost on disk and the `.output` symlink still resolves correctly.

This also means the promised "you will be notified automatically when it completes" behavior silently fails in this scenario: no notification is delivered to the post-rollover session, and there's no indication to the assistant/user that the agent's outcome is now orphaned rather than merely delayed.

### Impact
This has happened repeatedly (5+ times across sessions per our own usage) and is expensive: the only recovery is manually locating and reading the raw JSONL transcript file by path, which isn't part of the documented/expected workflow and risks overflowing context if not filtered carefully. For a user relying on background dispatch for real parallelism, this makes the feature unreliable across any turn that triggers compaction.

### Suggested fix
- `SendMessage`'s resume logic should search across *all* session directories for a given agent ID within the project, not just the current session's own subagent folder (the ID is already globally unique).
- Alternatively/additionally, when a session rollover occurs, in-flight or completed background agents launched under the prior session ID should be re-associated with the new session so notifications and resume both continue to work.
- At minimum, the error message should distinguish "never existed" from "exists but is orphaned under a different session" so the caller knows to fall back to direct transcript reading rather than assuming the agent vanished.

Begin at the sdk-ts entrypoint and trace background Agent dispatch through session rollover, ListAgents, and SendMessage resume handling. Reproduce using the two session IDs and the on-disk subagent transcript; done means a completed agent remains resumable and its completion notification reaches the rolled-over session.

Written by the indexing model from the issue text.