Add baseline CI — repo currently has no workflows

[epikalmit]

Summary

Commits 8437139 (chore(ci): remove upstream Prysm workflows) and
49d9f8a (chore(ci): remove orphan gomodtidy composite action) removed
all of .github/workflows/ and .github/actions/. That was the right call
— the upstream workflows pointed at Prysmatic Labs infra that this fork
can't use — but the result is that the repo has no CI at all right now.

A push that breaks go build or fails go test will go undetected until
someone runs it locally. For a consensus-client fork with custom state-
transition logic (the inactivity-exit patch at
beacon-chain/core/epoch/epoch_processing.go), that's risky.

Proposed scope (minimal first PR)

A single .github/workflows/go.yml that runs on push and PR:

• go build ./...
• go test ./beacon-chain/core/epoch/... ./beacon-chain/core/altair/... ./cmd/prysmctl/...
  — the three packages the fork actually modifies, to keep CI time bounded
  while still gating the diff. Full go test ./... can come later.
• go vet ./...

I'd suggest deliberately not porting upstream's fuzz.yml,
clang-format.yml, horusec.yaml, check-specrefs.yml, or
check-logs.yml in this first pass — they depend on external services
(Horusec, ethspecify, fuzzit) and configuration this fork hasn't decided
on yet. Tracking those as follow-ups is fine.

Questions for maintainers

1. Runner choice — GitHub-hosted ubuntu-latest, or is there
   self-hosted runner infrastructure that should be used (Prysm's old
   workflows used a mix)?
2. Go version — pin to the version in go.mod, or test against a
   matrix?
3. Bazel build verification — the project has BUILD.bazel and
   MODULE.bazel; should CI also run bazel build //...? Bazel CI is
   meaningfully slower and pricier, so I'd default to "no for now, file a
   follow-up."
4. Branch protection — once the workflow exists, is there interest in
   making it a required check on main?

If the answers are "ubuntu-latest, go.mod version, skip Bazel, yes
required check," I can have a draft PR up quickly.