[Feature]: Refactor catalog entry tests to generic discovery-based validation

[mrhillsman]

Problem Statement

The current internal/workloads/catalog_entries_test.go hardcodes per-entry assertions (specific param counts, role names, etc.). Every time a catalog entry is added or modified, the test file must be manually updated. This doesn't scale as the catalog grows.

Proposed Solution

Rewrite catalog_entries_test.go with a single generic discovery loop that globs catalog/*/ at test time and validates each entry against universal invariants:

• LoadCatalogEntry succeeds
• entry.Schema() returns a non-nil ParamSchema
• entry.Factory() produces a non-nil Workload
• wl.CloudInitUserdata() succeeds and starts with #cloud-config
• wl.Name() matches the directory name
• If entry.IsMultiRole(): cast to MultiVMWorkload, call UserdataForRole for each role in RoleDistribution()
• If storage declared: wl.DataVolumeTemplates() length matches entry.Manifest.Storage
• If service declared: wl.RequiresService() is true
• Skip entire suite if catalog/ directory doesn't exist
• No assertions on specific param names, counts, or role names

Reuses existing parseYAML helper from helpers_test.go.

Alternatives Considered

Keep per-entry test blocks with explicit assertions — precise but requires test code changes for every catalog entry addition.

Area

Testing, Workloads

Architecture Layer

Layer 3 - Workload Definitions (workloads, registry)

Additional Context

Implementation plan: docs/plans/write-two-catalog-workloads-wiggly-lerdorf.md (section 1)

Files changed:

File	Change
internal/workloads/catalog_entries_test.go	Rewrite: generic discovery loop

Verification:

ginkgo -v --focus "Shipped catalog entries" ./internal/workloads/
go test ./...