Summary

Fixes #511.

Repositories that have pull requests disabled return HTTP 404 from the /pulls endpoint (e.g. animetosho/uploader-php-ext, the repo from the issue). The backup previously let that 404 propagate out of backup_pulls, past the per-repo handler (which only catches RepositoryUnavailableError), aborting the entire run.

backup_pulls now catches the 404 from the pull listing, logs that the repository's pull requests are disabled, and continues with the rest of the backup.

Details

• The pull listing is fetched lazily (retrieve_data(..., lazy=True)), so the 404 surfaces during iteration — the guard wraps the iteration accordingly.
• The per-pull detail fetch used by --pull-details was moved into a separate phase outside the disabled-feature guard. This way a 404 on a single pull (e.g. one deleted/transferred between listing and detail fetch) propagates normally instead of being misreported as the whole feature being disabled, which would otherwise silently discard every already-collected pull.
• Hardened the existing 404 handlers in backup_security_advisories and backup_hooks: they now match on HTTPError.code == 404 rather than "404" in str(e), which could false-match a "404" appearing elsewhere in an error message or URL.

Scope note

Only /pulls returns 404 for this scenario. I verified against the issue's repo that /issues, /milestones, /labels, and /releases all return 200 (empty payloads) when issues are disabled, so no handling was needed there.

Testing

Tested against animetosho/uploader-php-ext and my own repos.