feat(provider): add a refresh strategy for github app installations

[grs]

Summary

Add gateway-managed minting and rotation of GitHub App installation tokens. Operators configure an app and installation with explicit repository and permission scope; long-running workloads retain access
across token rotations without receiving the app’s private key.

Related Issue

Fixes #3941

Changes

• Add the github_app_installation refresh strategy, including RSA JWT signing, scoped token requests, expiry handling, and secret-free failure diagnostics.
• Store app private keys through the credential driver and reuse existing refresh configuration, status, and rotation commands.
• Add an importable GitHub App profile supporting API access and Git HTTPS clone/fetch.
• Update protobuf, CLI, TUI, Go SDK, and documentation.
• Add independent GitHub E2E coverage with local HTTPS fixtures and real gh and Git clients.

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[johntmyers]

@grs In general we'd like to see issues that propose the features prior to PRs. This is something we will start enforcing through automation eventually. I'm also a bit concerned with how much change amplification there is to support unique auth refresh strategies like this. It's worth discussing at the next community call IMO. I'm curious if there are ways to support this type of functionality for specialized auth services as third party services that can interface with the public Providers API

[nyoungstudios]

@grs In general we'd like to see issues that propose the features prior to PRs. This is something we will start enforcing through automation eventually. I'm also a bit concerned with how much change amplification there is to support unique auth refresh strategies like this. It's worth discussing at the next community call IMO. I'm curious if there are ways to support this type of functionality for specialized auth services as third party services that can interface with the public Providers API

I just came across this OpenShell project yesterday and am not an expert by any means here. Although, I thought I bring this up with regards to needing to support specialized auth services. I have used this External Secrets Operator for an GitHub App on my own project on Kubernetes which does achieve the same thing that is being proposed here (refreshing the GitHub token without exposing the private key). You can install it with Helm too. The only snag I found when setting this up is that the refreshed GitHub token should be mounted as a volume on a pod. And you'll need a wrapper around the gh cli or whatever GitHub client to read from the secret file. If you just mount the secret directly as an environment variable on a pod, it won't receive the refreshed version.

[grs]

In general we'd like to see issues that propose the features prior to PRs. This is something we will start enforcing through automation eventually.

@johntmyers I am sorry, that was certainly a mistake on my part. I should have opened an issue and will be sure not to forget to do so going forward.

I'm also a bit concerned with how much change amplification there is to support unique auth refresh strategies like this. It's worth discussing at the next community call IMO. I'm curious if there are ways to support this type of functionality for specialized auth services as third party services that can interface with the public Providers API

It is certainly possible for something external to manage the refresh. The value of having it in OpenShell is operational simplicity. Built-in support for GitHub Apps makes OpenShell more attractive for cases where those are in use.

The main source of the amplification I believe is the use of a closed enum for the different 'refresh strategies', meaning every new strategy needs to change the proto to add a value that selects it. That in turn affects the cli, tui and sdks.

The amplification is perhaps also not as big as it may first appear. Roughly 72% of this diff is tests or test support. - Proto/storage/Go SDK propagation is 8 files but only 42 changed lines.