fix(publisher): treat GitHub device-flow slow_down as retriable

[developer-ishan]

Summary

• Handle GitHub's OAuth device-flow slow_down response per RFC 8628 §3.5 — treat it as retriable and bump the polling interval by 5 seconds, instead of bailing with a fatal error.

Fixes #1289.

Why

pollForToken in cmd/publisher/auth/github-at.go only treats authorization_pending as retriable. Every other response from GitHub's token endpoint — including the non-terminal slow_down signal — falls through to:

return "", fmt.Errorf("token request failed: %s", tokenResp.Error)

So users hitting GitHub's polling rate-limit get:

Error: login failed: error polling for token: token request failed: slow_down

…and have to re-run mcp-publisher login github from scratch, which is especially painful because slow_down is more likely when the user takes more than a few seconds to enter and authorize the device code.

Per RFC 8628 §3.5, slow_down is defined as:

A variant of "authorization_pending", the authorization request is still pending and polling should continue, but the interval MUST be increased by 5 seconds for this and all subsequent requests.

Change

Treat slow_down the same as authorization_pending but increase interval by 5 seconds before sleeping, matching the RFC exactly.

A possible follow-up (not in this PR, to keep the diff minimal): seed the initial interval from DeviceCodeResponse.Interval (already parsed but currently unused) instead of hardcoding 5. Happy to do that here or as a separate PR if preferred.

Test plan

• go build ./cmd/publisher/... — clean
• go test ./cmd/publisher/auth/... — passes
• gofmt -d and go vet ./cmd/publisher/auth/... — clean
• CI make check (lint + integration tests)

I could not exercise pollForToken from a unit test without refactoring GitHubAccessTokenURL to be injectable, which felt out of scope for a bug-fix PR. Glad to add that refactor + a table-driven test for authorization_pending / slow_down / fatal errors in a follow-up if maintainers want it.