ci(security): close OSSF Scorecard Dangerous-Workflow and Pinned-Dependencies findings

[mrz1836]

What Changed

• .github/workflows/e2e-smoke.yml — pinned actions/checkout@v4 and actions/setup-go@v5 to the same full SHAs already used by build.yml (actions/checkout@de0fac2… v6.0.2 / actions/setup-go@4a36011… v6.4.0). Closes the two Pinned-Dependencies Scorecard alerts on e2e-smoke.yml:35 and e2e-smoke.yml:38.
• Dockerfile — added a comment above FROM alpine:3.23 explaining why the base image is intentionally not digest-pinned (multi-arch manifest list consumed by the matrix amd64 + arm64 build; Dependabot's docker ecosystem already tracks weekly). No functional change. Targets the Pinned-Dependencies Scorecard alert on Dockerfile:13 (to be dismissed in the UI as Won't Fix).
• .github/workflows/build.yml — added a Resolve and verify build SHA step at the top of both build-and-push and merge-manifest. The step:
  • For non-workflow_run events, falls through to ${{ github.sha }}.
  • For workflow_run events, asserts workflow_run.head_sha is either reachable from main (gh api compare/main...<sha> returns identical or behind) or is the tip of a v* tag (gh api git/refs/tags/<branch> matches head_sha). Otherwise the job fails.
  • Exposes the verified SHA as steps.resolve_sha.outputs.sha. The checkout ref: and the SHA_TAG env vars in merge-manifest now consume that output instead of feeding workflow_run.head_sha directly into actions/checkout / imagetools. Targets the critical Dangerous-Workflow Scorecard alert on build.yml:129.
• .gitleaksignore — added the working-tree fingerprint variant for the existing e2e fixture meta.json so go-pre-commit's local scan honors the same exemption that the committed-history scan already had. Drive-by fix; the file was added in Add e2e tests with real block data #136 and was breaking every local commit on main.

Why It Was Necessary

OSSF Scorecard flagged 4 open code-scanning alerts on main (1 critical Dangerous-Workflow, 3 medium Pinned-Dependencies). The repo already has strong supply-chain hygiene elsewhere — build.yml, codeql-analysis.yml, and scorecard.yml pin every action to a full SHA, and dependabot.yml bumps github-actions and docker weekly. The newly-added e2e-smoke.yml and the alpine:3.23 base slipped through; the workflow_run-triggered checkout in build.yml was added in #128 to gate image publishing on GoFortress and is logically safe but matches Scorecard's static dangerous pattern.

Testing Performed

• actionlint .github/workflows/build.yml .github/workflows/e2e-smoke.yml → clean.
• go-pre-commit run → all 6 checks pass.
• Local docker build was not run — Docker daemon isn't running on this machine and the Dockerfile change is comment-only.

Impact / Risk

• build.yml SHA verification: Adds two gh api calls per build (one in build-and-push, one in merge-manifest) using secrets.GITHUB_TOKEN. No functional change for pull_request / workflow_dispatch paths (early-exits to github.sha). For workflow_run paths, the gate is stricter — a head_sha not reachable from main (or not matching its v* tag) now fails the build instead of silently being checked out. This is the intended trust-boundary tightening.
• e2e-smoke.yml pins: Dependabot's github-actions ecosystem will continue to bump these SHAs.
• Dockerfile: comment-only, no rebuild needed.
• .gitleaksignore: local-only effect; CI scan was already passing.

Caveat noted in plan: Scorecard's dangerous-workflow check is pattern-based. If the matcher only looks for actions/checkout inside a workflow_run workflow regardless of ref: source, the build.yml alert may persist after re-scan. Fallback options if that happens:

• Convert build.yml to a workflow_call reusable workflow invoked from the end of GoFortress (Scorecard does not flag workflow_call).
• Drop workflow_run and trigger directly on push to main / v*, relying on branch protection (GoFortress required check) for the gate.

Post-merge follow-up

1. Trigger Scorecard via workflow_dispatch and confirm the two e2e-smoke.yml Pinned-Dependencies alerts close.
2. Dismiss the Dockerfile:13 Pinned-Dependencies alert in the GitHub code-scanning UI: Reason: "Won't fix" — Comment: "Multi-arch base image; manifest-list pinning offers no real supply-chain benefit over weekly Dependabot bumps and complicates per-arch builds. See Dockerfile comment."
3. Watch the next workflow_run-triggered build to confirm the verification step passes for a real push to main.
4. If the build.yml Dangerous-Workflow alert persists after re-scan, escalate to the workflow_call fallback above.

Notifications

• @mrz1818