Replace the hardcoded parenthetical with the actual error message so the log is always accurate:

core.info(
  `Skipping failure tracking issue creation/update: token lacks issues:write permission (${ getErrorMessage(error) })`
);

This preserves the actionable explanation ("token lacks issues:write permission") while surfacing the exact error text that matches the real scenario — "insufficient permissions", "resource not accessible by personal access token", or "resource not accessible by integration" — so anyone reading the Actions log can immediately correlate it with the correct GitHub API error documentation.

Add a third test case in the same describe block:

it("returns true for 403 resource not accessible by personal access token", () => {
  expect(
    isIssueWritePermissionError({ status: 403, message: "Resource not accessible by personal access token" })
  ).toBe(true);
});

All three listed patterns should be covered so a future edit to the match list produces a test failure rather than a silent regression.

Either:

1. Tighten the match to the specific GitHub token-permission phrasing ("insufficient scopes" is more precise for that class of error, though you should verify the exact strings returned by your Octokit version), or
2. Rename the predicate to isTokenPermissionError and document in its JSDoc that it is deliberately broad across all 403 permission flavors so future callers understand the intent.

If the function is truly meant to be a general-purpose 403-classifier for any GitHub write, the current name isIssueWritePermissionError is misleading; callers will be surprised when it also matches a 403 on a label API call.