[bug] GitHub App installation tokens (ghs_) are rejected by the credential preflight

Start in packages/backend/src/github.ts at getGitHubReposFromConfig and the GET /user preflight around lines 115 and 185; compare the existing token detection and authentication handling in github.ts and utils.ts:163-177. Check the existing GitHub token-type unit test and verify that a ghs_ token can discover repositories without the user-only preflight failing; consider the users: paths at lines 251 and 322 as additional scope.

Describe the bug

Sourcebot recognises GitHub App installation tokens as a supported token type —
GitHubTokenType declares 'app_installation' and detectGitHubTokenType() returns it
for the ghs_ prefix (packages/backend/src/github.ts:26,43), with a unit test asserting
exactly that.

However, a connector configured with one fails before listing a single repository.
getGitHubReposFromConfig validates the credential with GET /user (github.ts:185) and
rethrows on failure. An installation token authenticates as an installation, not a user,
so GitHub answers:

403  "Resource not accessible by integration"

No permission grant can satisfy this, because there is no user to return. The check also
cannot be skipped: its guard is isAuthenticated: !!token (github.ts:115), so the only
way to avoid it is to configure no token at all — which limits indexing to public
repositories.

Expected: a connector configured with an installation token indexes normally.
Actual: repository discovery aborts with a 403 at the preflight.

The inconsistency is the bug: every other GitHub path already handles installation
tokens correctly. getRepoAuth builds x-access-token: <token> git credentials from one
(utils.ts:163-177), which is precisely the documented form for installation tokens, and
repos.listForOrg accepts one. Only the preflight rejects it.

Note - The credential is simply an installation token supplied as an ordinary
connector token.

To reproduce

1. Register a GitHub App, install it on an organisation, grant Contents: read and
   Metadata: read.
2. Mint an installation token:
   POST /app/installations/{installation_id}/access_tokens (returns a ghs_… token).
3. Configure a GitHub connector with that token and an orgs entry:

   { "type": "github", "token": { "env": "GITHUB_TOKEN" }, "orgs": ["my-org"] }
   

4. Start Sourcebot and trigger a connection sync.

Result: sync fails immediately. Logs show Failed to authenticate with GitHub and a 403
Resource not accessible by integration. Zero repositories are discovered.

Substituting a personal access token for the same organisation works, which isolates the
failure to the token type rather than to permissions or configuration.

Sourcebot deployment information

Sourcebot version (e.g. v3.0.1): v5.1.12 (docker.sourcebot.dev/sourcebot-dev/sourcebot),
also reproduced against main at the time of writing.

Additional information

Two further user-context calls exist in the same file and will fail the same way for the
same reason, though only when users: is configured rather than orgs::

• repos.listForAuthenticatedUser → GET /user/repos (github.ts:251)
• rest.search.repos → GET /search/repositories?q=user:… (github.ts:322)

A fix for the preflight is proposed in the linked pull request. Happy to extend it to
those two paths if you would prefer them handled in the same change.