[rgarcia]

Adds GitHub's workflow dependency lockfile. .github/workflows/actions.lock records the exact commit behind every action the workflows use, and the runner refuses to run an action whose resolved commit doesn't match. A moved or hijacked tag on a third-party action can no longer change what runs in CI.

• Added .github/workflows/actions.lock, generated with gh actions-lock --no-narrow so the generator's existing uses: lines (commit-SHA pins) stay exactly as they are; the lockfile records those SHAs.
• One uses: line changes, in release-please.yml: pnpm/action-setup was pinned to f40ffcd…, the SHA of the annotated v4 tag object rather than a commit, which the lockfile can't record. It is now pinned to b906aff…, the commit that tag points to, so the same code runs as before.
• kernel/security-workflows/.github/actions/llm-credentials stays pinned by commit SHA and is recorded in the lockfile.

Not covered: job-level reusable workflow calls (semgrep.yml, vuln-remediation.yml → kernel/security-workflows/...@main). The redis:7-alpine service container in update-mcp-coverage.yml is also not covered (the lockfile pins actions, not images).

Codegen / staging: these workflows are generated and promoted from kernel-node-sdk-staging. This PR only adds a new file (plus the one-line pnpm fix), so promotion merges shouldn't conflict. But when staging changes a uses: line, actions.lock has to be refreshed with gh actions-lock --no-narrow in the same change, or CI/publish here will fail. The release-please.yml pnpm pin on staging has the same tag-object SHA and should get the same fix there.

• gh actions-lock --verify passes (all 10 workflows valid).
• To change an action version later: edit the uses: line, run gh actions-lock --no-narrow, and commit both files.

[github-actions]

Semgrep: 55 findings detected

Too many findings to triage automatically (limit: 20).

Next steps:

1. Review the workflow run
2. Add // nosemgrep or .semgrepignore entries for accepted patterns
3. Fix genuine issues and re-push

[rgarcia]

Closing in favor of https://github.com/kernel/kernel-node-sdk-staging/pull/19 (same change: actions.lock via gh actions-lock --no-narrow plus the pnpm pin moved to the commit b906aff). Landing it on staging keeps the staging→production back-sync a fast-forward. It has already been promoted into next, where CI and Release Please passed with the lockfile enforced, and it reaches main with the next release.