InstallationPermissions is missing organization_private_registries

この issue は github/apps.go 内、特に InstallationPermissions 構造体に関するものです。既存のフィールドとその順序を確認してください。正しい JSON タグを付けて 'OrganizationPrivateRegistries' フィールドを追加します。GitHub API ドキュメントでパーミッションキーを確認して検証してください。構造体が正しくマーシャル/アンマーシャルされることを確認するためにテストを実行してください。

Summary

InstallationPermissions in github/apps.go has no field for the organization_private_registries
App permission, so callers cannot read it off an installation and cannot request it when scoping
down an installation access token.

Detail

The endpoints it governs are already supported: github/private_registries.go, added in #3785 and
extended for OIDC in #4159. The permission itself is not modelled.

GitHub returns the key today. GET /orgs/{org}/installations includes it in an installation's
permissions map for any App that holds it:

"permissions": {
  "organization_private_registries": "read"
}

The REST documentation for the private registries endpoints also names it, in the
"Fine-grained access tokens for ..." section of each endpoint, as "Organization private registries"
organization permissions, with GitHub App installation access tokens listed as supported:
https://docs.github.com/en/rest/private-registries/organization-configurations

Two consequences of the missing field:

• The value is silently dropped when an installation is unmarshalled, so
  Installation.GetPermissions() cannot report it.
• Apps.CreateInstallationToken cannot request it via InstallationTokenOptions.Permissions, so
  Go code cannot mint a token narrowed to private registries. Callers have to fall back to an
  untyped request that builds the permissions JSON by hand.

Checked on master and on v92.0.0. Alphabetically the field belongs between
OrganizationPreReceiveHooks and OrganizationProjects.

One note for anyone checking this against the published schema: the app-permissions schema in
octokit/openapi has no occurrence of private_registr at all. That schema also omits
organization_dependabot_secrets, which this struct already carries, so its omission is a gap in
the schema rather than evidence that the permission does not exist.

Proposed fix

Add the field and its generated accessor. I am planning to work on this and will open a PR.