Bash tool's gh rate-limit <system-reminder> still fires on output that merely mentions rate limits (2.1.267; follow-up to #52745)

#52745 reported that the 2.1.119 fix (spurious "GitHub API rate limit exceeded" hints on PR titles) was incomplete; it was auto-closed as inactive, not fixed. On 2.1.267 the heuristic still fires on stdout text rather than on an actual rate-limit response:

• gh api repos/<owner>/<repo>/pulls/<n>/comments returning review comments whose bodies discuss rate limits
• gh search issues --repo anthropics/claude-code "spurious rate limit", whose results have the phrase in their titles
• a non-gh command, grep -n "rate limit" ~/.claude/cache/changelog.md, whose output contains the changelog's own fix note

Each time, gh api rate_limit --jq .resources.core reported used: 0.

The injected block, verbatim:

<system-reminder>GitHub API rate limit exceeded (5,000/hr shared across all tools and agents). Run `gh api rate_limit --jq .resources` and sleep until reset before further gh calls. If polling in a loop, use ScheduleWakeup instead of retrying.</system-reminder>

Why it matters: the reminder tells the agent to "sleep until reset before further gh calls", so a false positive can stall an agent for up to an hour with its quota untouched. It is worst on exactly the work most likely to mention rate limits, such as reviewing a PR about rate limiting.

Suggested fix: trigger only on a real limit, meaning a gh invocation that failed with HTTP 403/429 plus x-ratelimit-remaining: 0 or Retry-After in its stderr, rather than a substring anywhere in stdout.

Environment: Claude Code 2.1.267, Claude desktop app 2.2553.1, macOS (Darwin 25.6.0).