ci: trusted publishing, and build before linting

[eladchen]

Last of the four repos to get the treatment eslint-config got, where it replaced
the credentials that expired in August. This one is deliberately last: it is the
tool every other repo releases with.

The workflow was already red

Every run of Build & Release since at least September 2025 has failed, including
the four open dependabot PRs:

scripts/release.js:1:21
Package path . is exported from package ... but no valid target file was found
n/no-missing-import

scripts/release.js imports this package by name, and that self reference
resolves through exports into build/, which does not exist until the build
runs. Lint ran first. Moving Build ahead of Lint Code fixes it — the same
ordering fix web-app made for the same reason. This branch is the first green run
of this workflow in a year.

Trusted publishing

• NPM_TOKEN is gone; npm mints a short lived publish token from the workflow's
  OIDC identity. GitHub API calls use GITHUB_TOKEN instead of the bot PAT, and
  checkout no longer takes a token.
• .nvmrc v18.18.0 -> v24.13.0, because trusted publishing needs npm 11.5.1+.
  engines is untouched.
• provenance: true in publishConfig, since NpmPublishPackageCommand builds
  the publish args itself and has no --provenance option.
• pull-requests: write alongside issues: write. This package's own
  GithubCreateIssueCommentsCommand comments on whatever the released commits
  reference, and a bare #12 resolves to a pull request as readily as an issue.
  Without the permission the command throws and the entire release rolls back —
  that is what happened on eslint-config 3.0.1.
• workflow_dispatch, so a release can be started deliberately.
• Action bumps (checkout v6, setup-node v6, cache v5), which also supersede the
  open dependabot PRs.

Before the next release

A trusted publisher connection for @abstracter/atomic-release on npmjs.com:
package Settings -> Trusted publishing, abstracter-io / atomic-release /
build-and-release.yml, with Allow npm publish ticked.

Worth fixing here later

Two rough edges this migration surfaced in the library itself:

1. GithubHttpCommand logs X-Accepted-GitHub-Permissions as
   GitHub Missing Permissions: ... on any non-ok response. That header lists
   what the endpoint accepts, not what the caller lacks, so a plain 404 prints a
   misleading warning.
2. A 404 on an issue comment is tolerated, but a 403 throws and rolls back a
   release that had already tagged and published nothing wrong. Referencing
   another repo's issue as owner/repo#N is enough to trigger it.