chore(lint): run all CI linters locally via make targets

[IrvingMg]

Description

Add per-tool make lint_* targets and a make lint umbrella that run all four CI linters (golangci-lint, cspell, commitlint, license-eye) locally via containers, so contributors can catch all CI lint failures before pushing.

Notes:

• Merging should fire the publish workflow automatically (first publish creates linters-npm:v0.1.0).
• Updating CI workflows to invoke these make targets will land in a follow-up PR.

Related issues

• Part of Add unified make target to run all CI linters locally #491

How was this tested?

Ran all lint targets together via make lint, and individually using make lint_*.

LLM usage

Claude Opus 4.6

Checklist

• I have read the contribution guide.
• The linter passes locally (make lint).
• The e2e tests of at least one tool pass locally (make test_ctr, make test_nerdctl, make test_docker, make test_crictl).
• If LLMs were used: I have read the llm policy.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	cef669a
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/69de3a59c22e740008ea7bec

[cmainas]

Hello @IrvingMg ,

I have tested this out and it works well. A couple of questions / comments:

• Would it be better to move the linters directory somewhere else than .github? Not really sure where it should be placed.
• I think we should still use the official actions in the CI rather than use the container images. They already offer reusable actions and we can easily update the versions (through dependabot) and customize them through the action inputs.

[IrvingMg]

Hey @cmainas, thanks for giving it a try.

About keeping the official actions in CI, that sounds good to me. We can keep this issue focused on local development. Since the custom npm image should be rebuilt when something changes in the linters directory, the risk of differences between CI and local setup should stay low.

About where the linters should live, those configs are still used by the CI workflows, so they need to stay close to CI in some way. It probably makes sense to keep them in .github/linters/ so we don’t need to update workflow paths without a good reason. That said, I don’t have a strong opinion here.