[Initiative] Catalog Validation in gitstore-api

[juliuskrah]

Summary

Implement catalog object validation inside gitstore-api as the authoritative validation layer, now that validation has been removed from gitstore-git-service. The git-service focuses solely on Git hosting and storage; validation is a domain concern that belongs in the API.

Validation will be invoked from git-receive-pack hooks in gitstore-git-service via a gRPC call to this API endpoint. The implementation is schema-driven using the Kubernetes-style frontmatter format introduced by #40.

Scope

In Scope

• Define a validation interface and engine inside gitstore-api for catalog object types: Product, Category, and Collection.
• Validate against the Kubernetes-style frontmatter schema introduced in [Initiative] Kubernetes-style Catalog Frontmatter #40 (apiVersion, kind, metadata, spec).
• Expose a gRPC endpoint (or internal callable) that gitstore-git-service pre-receive hooks can call during git-receive-pack.
• Return structured validation errors per file (file path, field, error code, human-readable message) usable by the git-service to relay the rejection reason back to the git client.
• Support future callers beyond hooks (admin UI pre-flight, CI pipeline checks, API mutations).
• Integration tests covering valid and invalid catalog objects for all three types.

Out of Scope

• Admission control policy engine (tracked as a subtask in [Initiative] ValidatingAdmissionPolicy Engine for Catalog Objects #106).
• Validation of non-catalog resource kinds.
• Runtime enforcement beyond the pre-receive hook path in this iteration.

Acceptance Criteria

• gitstore-api exposes a validation entry point for catalog objects callable from git-service hooks.
• Validation covers all required and optional fields for Product, Category, and Collection per the [Initiative] Kubernetes-style Catalog Frontmatter #40 schema.
• Structured error responses include file path, field name, error code, and description.
• A git push containing invalid catalog files is rejected with human-readable error messages surfaced to the git client.
• Integration tests cover valid objects, missing required fields, invalid field values, and uniqueness violations.
• Validation is invocable independently of the git push path (e.g. from admin UI or mutation pre-flight).

Subtasks

• [Initiative] ValidatingAdmissionPolicy Engine for Catalog Objects #106
• [Initiative] Config-Driven git-receive-pack Hook Orchestration and Admission Phase Routing #107

Dependencies

• Blocked by: [Initiative] Kubernetes-style Catalog Frontmatter #40

Tracking

• Milestone: TBD

[juliuskrah]

Linked to parent initiative #123 ([Initiative] Admission Validation Contract (Validating Phase Only)). This work should align with the validating admission interface contract defined there.