(orchestration): Inject service-catalog metadata into context hydration

## Component

API or orchestration

## Describe the feature

Extend context hydration so onboarded repositories can attach **structured service metadata** (ownership, dependencies, data stores, environment boundaries, non-negotiable conventions) alongside code and `AGENTS.md` content. Metadata should be resolved at task start and injected into the assembled prompt within the existing token budget.

## Use case

Agents working in large or polyglot monorepos often guess at ownership, blast radius, dependencies, and conventions because the codebase alone does not encode them—internal developer portals and service catalogs exist precisely to answer “who owns this, what does it talk to, what is non-negotiable.” Hydration today pulls issue/PR content, memory, and repo-local rules, but not a **system-of-record view** of the service being changed. Reducing that guesswork improves first-pass PR quality and review trust.

## Proposed solution

1. Add optional Blueprint / `RepoConfig` fields for a **service catalog source** (initially: static JSON/YAML in-repo path such as `.abca/service.yaml`, or S3 object keyed by repo).
2. Extend `context-hydration.ts` to fetch, validate (schema), and render a compact **Service context** block (owner, dependents, data classification hints, required checks).
3. Document schema in `docs/design/REPO_ONBOARDING.md`; mirror types in `cli/src/types.ts`.
4. Fail-open: missing or invalid catalog data logs a warning and omits the block (consistent with memory fail-open).

## Other information

- Complements **Dynamic onboarding artifacts** on the roadmap (generated summaries) with operator-authored or IDP-exported truth.
- Distinct from memory: catalog entries are versioned with the repo, not learned episodically.
- Related roadmap: `Untrusted hydration content boundaries` — catalog text should be framed as reference data, not instructions.

## Acknowledgements

- [ ] I may be able to implement this feature
- [ ] This might be a breaking change

## Acceptance criteria

- [ ] Blueprint can reference an optional service-metadata source per repo.
- [ ] Hydrated prompt includes a bounded Service context section when configured.
- [ ] Invalid catalog files do not block task execution; warning is emitted to orchestrator logs and `TaskEvents`.
- [ ] JSON Schema (or equivalent) published under `docs/design/` and validated in unit tests.
- [ ] Colocated tests under `cdk/test/handlers/shared/context-hydration.test.ts` cover happy path, missing file, and malformed schema.

Beginne mit cdk/.../context-hydration.ts und den Definitionen von Blueprint/RepoConfig, prüfe anschließend cli/src/types.ts und docs/design/REPO_ONBOARDING.md. Führe cdk/test/handlers/shared/context-hydration.test.ts aus, bevor du Tests für konfigurierte, fehlende und fehlerhaft formatierte Katalogdaten hinzufügst. Als erledigt gilt, dass der begrenzte Service-Kontext injiziert wird, wenn die Daten gültig sind, während ungültige Daten Warnungen protokollieren und die Ausführung nicht blockieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.