[Feature]: support and guidance for multi-repo products (microservices architecture)

### Problem Statement

Spec Kit currently provides guidance for monorepo scenarios, but many real-world products are built as multiple repositories (microservices), where each repository serves a different function within the same product.

For many organizations, monorepo is not viable due to constraints such as:

- security boundaries,
- team ownership models,
- compliance requirements,
- independent release cadences,
- operational limitations.

Without a dedicated multi-repo approach, applying Spec-Driven Development consistently at the product level becomes difficult, especially for cross-service changes.

### Proposed Solution

Add official support (feature and/or documentation) for a multi-repo product workflow tailored to microservices architectures.

Suggested scope:

- Define a way to represent a product as a logical grouping of multiple repositories/services.
- Support linking and tracking spec dependencies across repos.
- Provide a recommended workflow for cross-repo changes, including:
- creating/updating specs per service,
- dependency management,
- compatibility validation,
- release coordination.
- Establish conventions for versioning and traceability across repositories.
- Include practical, end-to-end examples for non-monorepo microservices.

### Alternatives Considered

Use monorepo guidance as-is
Not sufficient when monorepo cannot be adopted for organizational or technical reasons.

Keep ad-hoc team conventions per repo
Leads to inconsistent practices, weak traceability, and higher coordination overhead.

Rely only on external tooling/process docs
Helps partially, but lacks first-class, opinionated support within Spec Kit’s own workflow.

### Component

Specify CLI (initialization, commands)

### AI Agent (if applicable)

GitHub Copilot

### Use Cases

1. A product is composed of several microservices, each in its own repository.
2. A product-level feature requires coordinated updates to multiple services/specs.
3. An API contract change in one service affects dependent services in other repos.
4. Teams need clear mapping from product intent/spec to implementation across all involved repositories.
5. Release readiness depends on compatibility and sequencing across multiple repos.

### Acceptance Criteria

- [ ] Documentation clearly describes when and how to use a multi-repo workflow (especially when monorepo is not possible).
- [ ] A product-level model/grouping for multiple repos/services is defined.
- [ ] Cross-repo spec linking/dependency handling is documented (or supported as a feature).
- [ ] A recommended end-to-end flow for cross-repo changes is provided.
- [ ] Versioning and traceability conventions across repos are defined.
- [ ] At least one practical microservices example (non-monorepo) is included.

### Additional Context

_No response_

No files or tests are named. Start by reviewing the existing monorepo guidance and the CLI initialization and command workflows, then determine where a product-level multi-repository model could fit. Done means documenting or implementing cross-repo linking, dependency handling, versioning, release coordination, and a complete microservices example.

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