Repo-bound cloud session fails to start when the revision is a slash-containing branch name that exists on the remote

## Summary

When `claude --cloud` creates a repo-bound session, a revision whose branch name contains a slash (`team/branch` style) fails to resolve in the cloud VM — the session dies at the "Cloned repository" step with:

> The requested branch or commit was not found in the git_repository source. Check the spelling of the branch name, verify it exists on the remote, and ensure it hasn't been deleted or renamed.

The branch demonstrably exists on the remote. A slash-free branch name pointing at the **same commit** clones fine, which isolates the failure to the ref-name shape.

## Environment

- Claude Code 2.1.233 (native, macOS), claude.ai Max account
- Private repo under a GitHub org; sessions authenticate via the connected GitHub account
- Repro reaches the repo-bound path with `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1` (see #81776 for why that env var is needed on this machine at all — independent issue)

## Repro (controlled A/B at the same commit)

Both branches point at the same commit `65027490…`, both verified present on the remote via `git ls-remote` before each run:

```
# A: slash-free ref — WORKS
git push origin 65027490:refs/heads/tf1320-noslash
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --cloud "report git remote -v" --ref tf1320-noslash
# → session clones, `git remote -v` inside the VM shows the repo, works on a claude/… branch
# (session_014vdVpFGaZrivzFZ8ReMwzk)

# B: slashed ref — FAILS
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 claude --cloud "report git remote -v" --ref the-framework/log-row-wash
# → "The requested branch or commit was not found in the git_repository source" → "Session couldn't start"
# (session_01UJwbiJmfFQpVsVtbVquPDq)
```

Client-side debug logging confirms the request is well-formed in both cases — the session-create payload carries `"revision": "the-framework/log-row-wash"` and the CLI logs `[teleportToRemote] Git source: github.com//, revision: the-framework/log-row-wash` before the 200 response; the failure happens later, in the VM's clone step.

Also reproduced without `--ref`: the default pin to the current local branch fails the same way whenever that branch has a slash in its name (`git branch --show-current` → `the-framework/…`).

- `--ref main` → works
- `--ref tf1320-noslash` → works
- `--ref the-framework/log-row-wash` → fails (exists on remote, same commit as the working no-slash ref)
- default pin, current branch `the-framework/…` → fails

## Expected

Slash-containing branch names are legal git refs (and a common team convention, e.g. `feature/x`, `user/topic`). The revision lookup in the git_repository source should resolve them like any other branch, or the CLI should reject them at creation time with a clear message instead of producing a session that dies at provisioning.

## Impact

Any workflow whose branches are namespaced with slashes cannot hand off to a repo-bound cloud session from that branch — the session is created successfully and then fails to start, with an error that (incorrectly) suggests the branch does not exist.

Cross-refs: #81776 (CLI silently bundles when the GitHub-App preflight fails), #86268 (docs vs bundle-trigger behavior). This one is independent of both: it occurs on the repo-bound path itself.

Start with the `claude --cloud` repo-bound session path and the `--ref` revision handling described in the repro. Compare the working slash-free revision with `the-framework/log-row-wash`, then trace the later VM "Cloned repository" step; done means slash-containing remote branches resolve successfully or are rejected before session creation with a clear error.

Rédigé par le modèle d'indexation à partir du texte de l'issue.