fix(vcs): send the GitHub App ID as an integer in the JWT issuer claim

[levivannoort]

What breaks

generateAccessToken() puts the App ID into the JWT iss claim as the string it was read from:

$appIdentifier = $appId;   // ?string
$payload = ['iat' => $iat, 'exp' => $exp, 'iss' => $appIdentifier];

That encodes as "iss":"1234567". GitHub reads the claim as a JSON integer and answers every token request:

Status: 401 · {"message":"'Issuer' claim ('iss') must be an Integer"}

No installation token is ever issued, so all 94 GitHub e2e tests error. Six Bitbucket 403s are a separate issue, likely masked behind this.

It has been red for two days

test (vcs, linked) has failed on every run since 2026-09-02. The runs that looked green in between had zero vcs jobs — vcs only runs when the changed set reaches it, so a nats-only or queue-only PR never exercises it. It surfaced on #201 only because that touches bin/, which puts every package in scope.

This is not the staging cluster and not NATS: the vcs compose stack is gitea, forgejo, gogs, gitlab and a request-catcher, with no NATS service. The credentials are present too — GitHubTest::setupAdapter() calls markTestSkipped() when the App ID is empty, and the tests error rather than skip.

The fix

-$appIdentifier = $appId;
+$appIdentifier = ctype_digit((string) $appId) ? (int) $appId : $appId;

A client ID (Iv23li...) is a legitimate string issuer, so only an all-digit identifier is cast.

The test froze the defect

testInitializeVariablesSignsJwtWithPemString verified the signature and the path correctly, but its last assertion was:

$this->assertSame('5678', $claims['iss']);   // the exact shape GitHub rejects

So it passed the whole time the suite was down. It now asserts the type, and a second case covers the client-ID path. Seen red: reverting the one-line fix gives Failed asserting that '5678' is of type int.

Unit suite: 559 tests, 1127 assertions, all passing.