ci: enforce cached, Windows-tuned Go setup repo-wide

[bigboateng]

Why

go test/go build on windows-latest runs ~9m25s while the same jobs take
seconds on Linux/macOS. setup-go is only ~7s — the dominant cost is Microsoft
Defender real-time scanning of the many small object/link files the Go toolchain
writes during compile/test. No workflow had build caching or Defender exclusions.

What

Shared composite action — .github/actions/go-setup

• On Windows: Add-MpPreference -ExclusionPath for GOCACHE (%LOCALAPPDATA%\go-build),
  GOPATH/GOMODCACHE (%USERPROFILE%\go), the workspace, and RUNNER_TEMP, plus
  -ExclusionProcess go.exe. Wrapped in try/catch so it degrades gracefully.
• Always: actions/setup-go@v7 with module + build caching (keyed on go.sum
  where one exists, else go.mod).

Routed every Go job through it — boatstack-lab, pitot-lab, conformance,
deltawire-v7, deltawire-v8. The deltawire builds are reproducible
(-trimpath -buildvcs=false, pinned GOOS/GOARCH/CGO) and remain sha256-locked;
their existing lock checks validate byte-identical output in this PR.

Repo-wide enforcement — the policy is structural, not a thing to remember

• .github/scripts/lint_go_ci_policy.py: any job whose run: steps invoke
  go test|build|run|vet|install must include a step that uses: the shared
  action. Escape hatch: # ci-speed-policy: exempt(<reason>) (reason required).
• .github/workflows/ci-policy.yml runs the lint on any .github/** change.

Verification

• Lint passes locally over all 18 workflows; negative test confirms it flags a
  non-compliant job and honors the exempt marker.
• Watch this PR's CI: boatstack-lab / pitot-lab Windows Runtime job time
  (expected large drop), deltawire v7/v8 sha-locks still green, CI speed policy
  green.

Follow-up (separate public-repo PR): inline the same Defender + cache steps into
operatorstack/boatstack's hand-maintained ci.yml (can't reference this
repo's local action).