feat!: Add OIDC authentication support to PrivateRegistries

[mkushakov]

BREAKING CHANGE: PrivateRegistriesService is updated to API version 2026-03-10 with struct and response changes.

Update the PrivateRegistriesService to align with the GitHub Private Registries
API version 2026-03-10.

Changes:

• Add PrivateRegistryAuthType type with constants for token, username_password,
  oidc_azure, oidc_aws, and oidc_jfrog
• Add OIDC-related fields to CreateOrganizationPrivateRegistry and
  UpdateOrganizationPrivateRegistry: AuthType, TenantID, ClientID,
  AwsRegion, AccountID, RoleName, Domain, DomainOwner,
  JfrogOidcProviderName, Audience, IdentityMappingName
• Add ReplacesBase field to both Create and Update request structs
• Add SelectedRepositoryIDs field to PrivateRegistry response struct
• Change EncryptedValue and KeyID in CreateOrganizationPrivateRegistry
  to *string with omitempty (should be omitted for OIDC auth types)
• Change UpdateOrganizationPrivateRegistry() to return (*Response, error)
  since the API now returns 204 No Content

API docs: https://docs.github.com/rest/private-registries/organization-configurations?apiVersion=2026-03-10

Fixes: #4158.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.83%. Comparing base (fee8865) to head (a84603b).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4159      +/-   ##
==========================================
- Coverage   93.83%   93.83%   -0.01%     
==========================================
  Files         209      209              
  Lines       19685    19681       -4     
==========================================
- Hits        18472    18468       -4     
  Misses       1015     1015              
  Partials      198      198              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mkushakov]

@gmlewis thanks for initial review, but this PR is breaking change compared to master branch, not to latest release, since github/private_registries.go was introduced recently and was not yet released #4147
this is why it will be better to merge it before release, to avoid breaking changes

[gmlewis]

Thank you, @mkushakov!
This is the first GitHub v3 API version breaking change using their new "calendar-versioning" mechanism. As a result, we need to make some more changes in this PR.

According to our README.md:

### Calendar Versioning ###

As of 2022-11-28, GitHub has announced (broken link)
that they are starting to version their v3 API based on "calendar-versioning".

In practice, our goal is to make per-method version overrides (at
least in the core library) rare and temporary.

Our understanding of the GitHub docs is that they will be revving the
entire API to each new date-based version, even if only a few methods
have breaking changes. Other methods will accept the new version with
their existing functionality. So when a new date-based version of the
GitHub API is released, we (the repo maintainers) plan to:

* update each method that had breaking changes, overriding their
  per-method API version header. This may happen in one or multiple
  commits and PRs, and is all done in the main branch.

* once all of the methods with breaking changes have been updated,
  have a final commit that bumps the default API version, and remove
  all of the per-method overrides. That would now get a major version
  bump when the next go-github release is made.

So we need to override the per-method API version header in this PR according to the blog post, and I'm discovering that the blog post link is now broken.
The new link is:
https://github.blog/developer-skills/github/to-infinity-and-beyond-enabling-the-future-of-githubs-rest-api-with-api-versioning/

According to the blog post, the following header needs to be added to the updated endpoint:

X-GitHub-Api-Version: 2026-03-10

So this endpoint needs to add:

req.Header.Set(headerAPIVersion, "2026-03-10")

[Not-Dhananjay-Mishra]

@gmlewis Should we also change this URL? I ignore that in #3948 because it has github.com

[gmlewis]

@gmlewis Should we also change this URL? I ignore that in #3948 because it has github.com

Yes, please change this URL to example.com for consistency with the rest of this repo, @mkushakov.
Thank you!

[gmlewis]

@gmlewis thanks for initial review, but this PR is breaking change compared to master branch, not to latest release, since github/private_registries.go was introduced recently and was not yet released #4147 this is why it will be better to merge it before release, to avoid breaking changes

Thank you, @mkushakov! That does make sense.

However, I like to keep track of all breaking changes as we move through the release cycles for those people who are following all the changes as they happen, so let's leave this labeled as a breaking change... at the very least, it will alert those who worked on github/private_registries.go that their original implementation has breaking changes since they wrote it, which should help minimize any unnecessary surprises.