feat: Add basic spec parsing

[cullenmcdermott]

Summary

Add build spec types, YAML parsing, validation, and status writeback for the new eidos build command, plus declarative value mapping from clusterSpec fields to component overrides.

Motivation / Context

The runtime controller needs Eidos to provide a build subcommand that reads a spec file, generates OCI artifacts, and writes image references back. This MR is the foundation: spec file I/O and a declarative
resolver that translates clusterSpec fields into bundler-compatible value overrides. No templates involved — just a YAML config that maps source paths to target paths.

Fixes: HIPPO-4068
Related: ADR-0013, ADR-0018

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• Build/CI/tooling

Component(s) Affected

• CLI (cmd/eidos, pkg/cli)
• API server (cmd/eidosd, pkg/api, pkg/server)
• Recipe engine / data (pkg/recipe)
• Bundlers (pkg/bundler, pkg/component/*)
• Collectors / snapshotter (pkg/collector, pkg/snapshotter)
• Validator (pkg/validator)
• Core libraries (pkg/errors, pkg/k8s)
• Docs/examples (docs/, examples/)
• Other: pkg/build (new package)

Implementation Notes

• BuildSpec types match the runtime controller's DGXCRuntime struct (apiVersion, kind, spec, status) so the two can read each other's files.
• ValueResolver reads a mapping.yaml embedded via embed.FS. New mappings are just YAML — no code changes needed.
• Resolver outputs map[string]map[string]string, which plugs straight into config.WithValueOverrides().
• mapping.yaml has two example entries for now. Real mappings get added as we integrate.

Testing

make test  # 30+ test cases across spec and mapping

Covers: loading, field validation, writeback round-trip, clusterSpec extraction, nested path traversal, conditional mappings, embedded config loading.

Risk Assessment

• Low — New package, no changes to existing code, easy to revert
• Medium — Touches multiple components or has broader impact
• High — Breaking change, affects critical paths, or complex rollout

Rollout notes: N/A

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality
• I updated docs if user-facing behavior changed
• Changes follow existing patterns in the codebase
• Commits are signed off (git commit -s) — https://developercertificate.org/

[github-actions]

Coverage Report ✅

Metric	Value
Coverage	73.2%
Threshold	70%
Status	Pass

Coverage Badge

![Coverage](https://img.shields.io/badge/coverage-73.2%25-green)

Merging this branch will increase overall coverage

Impacted Packages	Coverage Δ	🤖
github.com/NVIDIA/eidos/pkg/build	93.75% (+93.75%)	🌟

---

Coverage by file

Changed files (no unit tests)

Changed File	Coverage Δ	Total	Covered	Missed	🤖
github.com/NVIDIA/eidos/pkg/build/doc.go	0.00% (ø)	0	0	0
github.com/NVIDIA/eidos/pkg/build/spec.go	93.75% (+93.75%)	32 (+32)	30 (+30)	2 (+2)	🌟

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Changed unit test files

• github.com/NVIDIA/eidos/pkg/build/spec_test.go

[mchmarny]

See comment above

[mchmarny]

/lgtm

[yuanchen8911]

prealloc lint fix — Line 221 in components_test.go changes allPaths := []string{} to var allPaths []string
//nolint:prealloc. Our PR #88 already fixes this differently (with make preallocation). Whichever merges second
will need a minor conflict resolution.

[valcharry]

/lgtm

[yuanchen8911]

/lgtm