Run golangci-lint from a task target so lint failures surface before CI

[arasHi87]

Closes

Closes #299

What & why

CI runs golangci-lint as its own job, but no task target did — so task test, task test-integration and task ci could all be green while CI failed on lint. That happened on #298: 40/40 packages passed locally, CI failed on a one-line ineffassign.

task lint now runs the linter inside the builder, and task ci includes it.

Two things make it the same analysis CI performs rather than an approximation, and both were found the hard way:

• Natively, not cross-compiled. GOOS=linux from a darwin host looked like the obvious fix and produced two SA5011 findings CI does not report — both false positives, on a deref that follows a t.Fatalf. Cross-compiling loses staticcheck's fact that testing.T.Fatalf is terminal, so it flags correct code. A target that invents failures is worse than no target.
• deps: [generate]. Without the bpf2go-generated types internal/bpf does not typecheck, and every dependent package is then analysed with degraded facts — silently. CI already runs task generate before lint for this reason.

No source changes: the SA5011s needed no fix and are not excluded either; running natively means they never appear.

Test plan

• Unit — task test
• Integration — task test-integration (40/40 packages)
• Bench-gate — not applicable, no hot-path change
• Scenario — not applicable
• Manual e2e on a live cluster — not applicable

Mutation-verified: reintroducing the exact ineffassign that failed CI on #298 makes task lint report 1 issues; reverting returns 0 issues. So the target actually catches the class of bug that motivated it.

Scope / deliberately not touched

internal/neutron/resolve_test.go — the two SA5011 findings there are false positives, so no code change and no exclusion entry. An exclusion would have been a lie that hid a real nil-deref later.

Notes

golangci-lint is pinned in the builder image to the version .github/workflows/ci.yml installs (2.12.2), with a comment on both sides to bump them together.

One cost: task setup must be re-run after pulling this, or task lint fails on a missing binary. Every other real task here (generate, binary, test-integration) already goes through the builder, so this follows the existing grain rather than introducing a new mechanism.

DoD

• Linked issue's DoD met — no handbook entry: a task target and a pinned tool version are repo mechanics, not durable team knowledge. The interesting finding (cross-compiling degrades linter facts) is recorded in comments at both call sites and in the issue.