[BUG] --resume <id> --bg forks the session even without --fork-session

What happens. claude --resume <session-id> --bg starts a new session with a new id. The original stays asleep, untouched and unreachable.

What I expected. The original session to wake and keep its id. --help documents --fork-session as "When resuming, create a new session ID instead of reusing the original (use with --resume or --continue)" — which states that reusing the original is the default and forking is opt-in. I did not pass --fork-session, so I did not expect a fork.

Why the distinction matters. A fork is not a slightly-different success. It splits ownership: the original holds the history and is what every other reference points at, while the fork is a second session that knows the same past and diverges from that moment on. If I wanted the original awake, I now have two sessions with a claim on the same work and no way to merge them.

The workflow this blocks. I run a fleet of long-lived sessions, each owning one piece of work, and they hand context to each other with cross-session messaging. A sleeping session cannot receive a message, so a handoff needs it woken first — and the only route available forks it, which is exactly the outcome I am trying to avoid. The practical result is that the sessions I most need to reach are the ones I cannot reach: the ones idle longest are both the most likely to be running on a stale picture and the only ones that require waking.

Reproduction.

1. Start a session, note its id, let it go to sleep.
2. claude --resume <id> --bg        # no --fork-session
3. `claude agents` shows a new session with a different id;
   the original is still listed as asleep.

What would fix it. Honour the documented default — --resume --bg without --fork-session reattaches to the existing id. If forking is deliberate for the background path specifically, then --fork-session's description is wrong and should say so.

Version. 2.1.228, macOS.

Related: #79830 (compact fork-resume retires the session id) and #76493 (resuming from the Agent View forks) report the same behaviour on other paths, which suggests it is systemic rather than specific to this invocation. #84058 requests agent-to-agent messaging with wake-on-delivery, which would make waking unnecessary — but that is a much larger request, and this is one behaviour that can be fixed on its own. #86082 is the other half of the same workflow problem: not being able to tell from the agent list which sessions are asleep in the first place.