Add support for private github repos via git:directory

[akirk]

Motivation for the change, related issues

Currently, WordPress Playground can only fetch git:directory resources from public Github repositories, private ones are not supported.

Related: #2182.

This PR adds Github OAuth authentication support for private repositories:

• Load blueprints that reference private GitHub repositories
• Fetch a token via Github OAuth and a user displayed dialog
• Store the credentials (in memory or localStorage in dev mode, as previously)

Note: Because it uses Github OAuth and thus requires a Github user, this is not intended for demoing plugins that reside in private repos, rather for developers to run code in Playground that resides in their own private repositories.

Implementation details

Authentication Flow

• Added token storage and authentication helpers to git-sparse-checkout.ts
• Git protocol functions now send HTTP Basic Auth headers for Github URLs
• Throws GitHubAuthenticationError on 401/403 responses

UI

• New modal prompts users to authenticate when accessing private repos

Technical Details

• Changed OAuth scope from public_repo to repo
• Full page reload after OAuth to retry blueprint with new token

Testing Instructions (or ideally a Blueprint)

Test with a private repository:

  {
    "steps": [{
      "step": "installPlugin",
      "pluginData": {
        "resource": "git:directory",
        "url": "https://github.com/YOUR-USERNAME/YOUR-PRIVATE-REPO",
        "ref": "HEAD"
      }
    }]
  }

Expected: Modal prompts for GitHub auth → redirects to GitHub → returns and loads repo successfully without showing modal again.

Verify: Public repos still work without auth, token persists in dev mode (localStorage), no modal persistence issues.

[akirk]

Thanks for the review, @adamziel. I have restructured this according to your feedback! I realize that we're modifying the parameters of the git:directory resource inside the blueprint but it seemed like the best way to trickle down the headers from the website to where we need it at the directory resource.

[adamziel]

Looking good, I only have that one note I left last week! Do we know what happens if the user connects oauth and still has no rights to that repo?

[akirk]

It will display an Playground error that the repo doesn't exist (404). (The thing I wrote before about gh-request-auth was not correct)

[akirk]

Thanks for the thorough review, @adamziel! I have addressed the issues you pointed out and also added some tests in 9b7ef83

[akirk]

Thanks, @adamziel. Sorry for the repeated problems with the CORS URLs. They made me rethink the approach slightly: We now avoid dealing with CORS URLs in the first place by determining the need for the git auth headers earlier and rewrapping a thrown git authenticating error with the original URL. I added tests for that as well.
This feels much cleaner and allowed me to use the existing staticAnalyzeGitHubURL().