(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.

まず cdk/.../context-hydration.ts と Blueprint/RepoConfig の定義から始め、次に cli/src/types.ts と docs/design/REPO_ONBOARDING.md を確認します。設定済み、欠落、形式不正のカタログデータに対するカバレッジを追加する前に、cdk/test/handlers/shared/context-hydration.test.ts を実行します。有効な場合は制限された Service context が注入され、無効なデータの場合は警告がログに記録されて実行をブロックしないことが完了の条件です。

索引モデルが issue の本文から書いたものです。