[Bug]: Branch-name generator retries in a tight loop against Claude's session-limit response instead of backing off

### Operating system

macOS

### Orca version

v1.4.147 (current, checked 2026-07-21). Note: Orca auto-updates, so the exact
version running during the 2026-07-17 incident described below isn't confirmed —
the local logs from that date don't carry a version banner.

### Details

The branch-name generator (the "Generate a git branch name" call Orca makes when
creating a worktree) doesn't detect when Claude responds with a session-limit message
and keeps retrying immediately instead of backing off until the reset time.

**Observed:** on 2026-07-17, across two worktrees, the branch-namer prompt
"Generate a git branch name" was retried roughly 4-5 times/minute for about an hour
(< />348 sessions total across both worktrees), each attempt receiving the same
response: "hit your session limit · resets 2pm (Europe/Madrid)". Confirmed by
sampling 3 session transcripts from that window — all three show the literal
prompt followed by the literal session-limit response, with no backoff between
retries.

**Suggested fix:** detect the session-limit / rate-limit response (text match or,
if available, a structured error type) on the branch-namer's call path specifically,
and stop retrying / back off until the stated reset time, instead of retrying
immediately.

**Possibly related:** stablyai/orca#9616 documents the same category of gap on a different call
path (the Claude usage-endpoint poller ignores `Retry-After` and keeps retrying
inside the throttle window, causing a self-sustaining 429 loop). This may be the
same systemic issue — "retry lanes don't respect Claude's own backoff/limit
signals" — showing up on a second code path (branch naming instead of usage
polling). Worth checking if the same fix class (respecting the limit signal /
resets_at) closes both.

### How can we reproduce it?

Not easily on demand — it requires the Claude account actually hitting its session
limit while a branch-rename call is in flight, which happens naturally with many
concurrent worktree/agent sessions active at once (as in this case).