Adopt Go PGO for neva CLI release builds (compiler path only)

[emil14]

Summary

Track minimal adoption of Go PGO for the neva CLI binary (compiler/tooling path only).

Scope is intentionally narrow:

• optimize cmd/neva build using go build -pgo=...
• do not include runtime PGO for generated user binaries yet

Why

We want a low-risk, low-effort compiler performance win without expanding into runtime optimization strategy right now.

Decisions captured

• PGO profile source can be any representative CPU profile (pprof) for the target binary.
• For now we optimize only the CLI binary (neva build/run/install/... process).
• Runtime PGO for generated programs is a separate, future pipeline.
• Prefer reproducible profile generation workflow for release engineering.

Proposed workflow (v1)

1. Generate/update a CLI-focused profile from representative CLI workloads.
2. Build release binaries with -pgo=<profile>.
3. Fail release build when profile is missing/empty.
4. Keep a fast local profile path and a fuller release-quality profile path.

Candidate profile sources

• CLI e2e scenarios (best signal for real compiler/tooling paths).
• Benchmark suite (useful supplemental signal).
• Combined profile is acceptable and likely preferable.

Acceptance criteria

• make pgo-profile (or equivalent) creates non-empty CPU profile for CLI optimization.
• make build for release consumes that profile via -pgo.
• README/CONTRIBUTING note explains how to refresh profile.
• Runtime PGO is explicitly documented as out-of-scope for this issue.

Out of scope

• Instrumenting generated user programs for runtime PGO.
• Adding runtime-specific PGO flags to neva build output pipeline.