ci(jfrog): keep dependabot off the Artifactory path

[BernardJen]

The symptom

All four open dependabot PRs — #65, #66, #67, #68 — fail at the same step, in 10–17s, before a single package resolves:

[Error] got unexpected server response while attempting to get JFrog Artifactory version:
server response: 401
{"errors":[{"status":401,"message":"Authentication is required"}]}

The cause

The JFROG_ENABLED guard was written for forked PRs, the obvious secret-less case. Dependabot PRs are the non-obvious one:

• The branch lives in this repo, so head.repo.full_name == github.repository is true and the guard waves them through. (Confirmed: head_repo=Lab271/labs-slidecue, actor=dependabot[bot].)
• But a dependabot-triggered run is given the dependabot secret store, not the Actions one — and JF_ACCESS_TOKEN exists only as an Actions secret. The repo's dependabot secret list is empty.
• vars are visible to dependabot, so vars.JF_URL != '' cannot gate this either.

The jf CLI therefore authenticates with nothing and gets a 401.

Why it surfaced only now

Nothing regressed — two changes landed close together:

• The Artifactory steps were added to ci.yml in ci(jfrog): publish build-info, and promote releases behind an approval #61. Dependabot PRs opened before that ran a workflow with no Set up JFrog CLI step at all (verified on Bump the npm_and_yarn group across 1 directory with 3 updates #60's 18:05 run, which took the plain Install dependencies path and passed).
• JF_URL and JF_PROJECT were set on the repo at 17:57 today, JF_ACCESS_TOKEN at 18:00.

So the first dependabot runs to see both the new workflow and the new config were the four raised this evening, and all four failed.

The fix

Add github.actor != 'dependabot[bot]' to the guard. Dependabot PRs fall back to plain npm ci against registry.npmjs.org, exactly as forked PRs already do.

Adding JF_ACCESS_TOKEN as a dependabot secret would also clear the 401, but that hands the Artifactory token to runs built from an automated dependency bump. These PRs change the lockfile; main re-resolves it through Artifactory on merge, so the dependency record is unaffected.

Note on #65

#65 is the regrouped successor to #51, which dependabot closed as superseded once the lint-and-types group from #64 took effect. Its eslint 10 peer conflict is fixed — verified locally that eslint@^10.9.0 resolves clean and lints clean on current main — but CI can't demonstrate that until this 401 is out of the way, since it fails before dependency resolution.

🤖 Generated with Claude Code