GitHub API rate limit errors are not handled correctly

Problem

When the GitHub API returns rate limit responses (HTTP 429 or 403 with X-RateLimit-Remaining: 0), the client treats them as generic errors and immediately fails the entire discovery/reporting cycle. There is no retry, no parsing of rate limit headers (Retry-After, X-RateLimit-Reset), and no distinction between rate limit errors and other HTTP errors.

ETag caching (#682) reduces API consumption but does not address what happens when rate limits are actually hit.

Current Behavior

All GitHub API call sites use the same error handling pattern:

if resp.StatusCode != http.StatusOK {
    body, _ := io.ReadAll(io.LimitReader(resp.Body, 1024))
    return nil, "", fmt.Errorf("GitHub API returned status %d: %s", resp.StatusCode, string(body))
}

This means:

• Rate limit responses (429, 403) are treated identically to permission errors, not-found errors, etc.
• GitHub's rate limit headers (Retry-After, X-RateLimit-Reset, X-RateLimit-Remaining) are completely ignored
• The entire discovery cycle fails on the first rate-limited request, losing all work done so far
• The GitHubReporter also doesn't use the shared httpClient, so it bypasses the ETag caching transport entirely

Affected Areas

• Issue discovery (internal/source/github.go)
• Pull request discovery (internal/source/github_pr.go)
• Status comment reporting (internal/reporting/github.go)
• Reporter client wiring (cmd/kelos-spawner/reconciler.go)

/kind bug

Start by tracing the shared error handling in internal/source/github.go and internal/source/github_pr.go, then compare reporter wiring in internal/reporting/github.go and cmd/kelos-spawner/reconciler.go. Run the existing Go tests for the affected packages. Done means rate-limit responses are distinguished using the stated headers, retries or partial-cycle behavior is defined, and the reporter uses the shared HTTP client.