parse and validate the nested `components:` block under schema_version 1

[joshua-temple]

Problem / why

A manifest may declare a nested components: block under schema_version 1 (or with
schema_version omitted). The parser must accept that block (each component owning paths,
tag_prefix, triggers, builds, deploys, and an optional environments subset) and load
it into the same component-major in-memory model F1 introduced. A manifest with no components:
block continues to parse exactly as today, as the single implicit default component.

Scope

This PR does:

• Accept a components: block in internal/config/parse.go and route it to a component parse
  path that reads the nested block into the component-major model (the declared components ARE
  the components; no synthesized default). This is gated on schema_version being omitted or
  1, NOT on a version bump.
• Add a component validator (internal/config/validate_components.go or equivalent): each
  component has a distinct tag_prefix, a safe name, non-empty paths, and at least one build
  or deploy. A component's environments, if present, must be a subset of the global ladder.
• Update internal/schema/manifest.schema.json to describe the component-major
  config.components, state.components.<name>.<env>, and latest_release.components.<name>,
  all under schema_version 1.
• Keep a manifest with no components: block on its existing parse and validate path,
  unchanged, loading as the single default component.

This PR does NOT:

• Implement per-component version math (V2) or per-component file generation (F4 / V3).
• Implement the env-subset behavior (X1) beyond validating the field shape.
• Change the single-component path.

Files / areas touched

• internal/config/parse.go - component parse routing.
• internal/config/validate_components.go - component validation.
• internal/config/types.go - the ComponentConfig shape (its full field set is exercised in
  V1; here, enough to parse and validate).
• internal/schema/manifest.schema.json - component-major shape under schema_version 1.

Tests and coverage required

• Unit tests: a two-component manifest parses and validates into the component-major model.
• Validation tests: duplicate tag_prefix rejected; missing prefix rejected; unsafe name or
  empty paths rejected; a component env subset that escapes the global ladder rejected.
• A test that a manifest with no components: block still parses and validates exactly as
  before (no regression).

Acceptance criteria

• A manifest with a nested components: block under schema_version 1 parses into the
  component-major model.
• The component validator enforces distinct prefixes, safe names, non-empty paths, and a valid
  env subset.
• The single-component path is unaffected.

Dependencies

Blocked by F1 (needs the component-major in-memory model to parse into).

[joshua-temple]

Done in PR #507: the nested components: block is parsed and validated under schema_version 1 (internal/config/validate_v1.go plus the componentConfig schema definition): path and tag_prefix are required per component, tag prefixes must be distinct, and repository-wide-only fields are rejected per component. Shipped in v0.12.0 and validated end to end by the fleet. Referenced with Refs rather than Closes, so it stayed open.