Feature Request: Milestone grouping extension for taskstoissues

### Problem Statement

`/speckit.taskstoissues` creates GitHub Issues from `tasks.md`, but all issues land flat in the repo with no milestone assignment. On any non-trivial feature (multiple user stories, phased delivery, or multi-repo workspaces), the issue list quickly loses structure. There is no way to track progress at the feature or delivery-phase level without manually creating GitHub Milestones and assigning issues after the fact.

### Proposed Solution

A lightweight extension that hooks into `after_taskstoissues` and groups the newly created issues into GitHub Milestones.

### Behaviour

1. After `taskstoissues` completes, the extension reads the task structure from `tasks.md` (which already organises tasks by user story or feature group).
2. For each top-level group (user story, feature, or phase), it creates or updates a GitHub Milestone with a matching title.
3. Each issue created by `taskstoissues` is assigned to its corresponding milestone.
4. If a milestone already exists with that title, the extension reuses it rather than creating a duplicate.

### Extension shape

```yaml
schema_version: "1.0"
extension:
id: "milestones"
name: "Task Milestones"
version: "1.0.0"
description: "Groups issues created by taskstoissues into GitHub Milestones by feature or user story"
requires:
speckit_version: ">=0.10.0"
commands:
- "speckit.taskstoissues"
provides:
commands:
- name: "speckit.milestones.assign"
file: "commands/assign.md"
description: "Create or update GitHub Milestones and assign issues from the most recent taskstoissues run"
hooks:
after_taskstoissues:
command: "speckit.milestones.assign"
optional: true
prompt: "Assign issues to GitHub Milestones?"
```

### Grouping logic

The natural grouping already exists in `tasks.md`. Tasks are organised under headings that correspond to user stories or feature areas. The extension maps each heading to a milestone. No new configuration is needed for the default case.

For teams that want custom grouping (e.g. by delivery phase rather than user story), a config file could allow explicit mapping:

```yaml
# .specify/milestones-config.yml (optional)
grouping: "heading" # default: use tasks.md headings as milestone titles
# OR
grouping: "custom"
milestones:
- title: "Phase 1: Core API"
match: ["T001*", "T002*", "T003*"]
- title: "Phase 2: UI"
match: ["T004*", "T005*"]
```

## Why an extension, not core

This adds project management structure on top of the existing workflow without changing the core `taskstoissues` behaviour. Teams that do not use GitHub Milestones are unaffected. The extension model keeps it opt-in and independently versioned.

### Alternatives Considered

Manual milestone assignment works for small features but does not scale to multi-story specs with dozens of tasks. External scripting is possible but loses integration with the SDD workflow and traceability from spec to milestone. GitHub Projects boards are complementary but different: milestones track delivery scope, projects track workflow state.

### Component

Specify CLI (initialization, commands)

### AI Agent (if applicable)

All agents

### Use Cases

1. When working on large features with multiple user stories, each story's tasks should map to a milestone so progress is visible at the story level, not just the individual issue level.
2. During phased delivery (e.g. "Phase 1: API, Phase 2: UI"), milestones give stakeholders a native GitHub view of which phase is complete without reading tasks.md.
3. In multi-repo workspaces where each repo runs its own taskstoissues, milestones provide cross-cutting delivery tracking that flat issue lists cannot.

### Acceptance Criteria

- [ ] Running /speckit.milestones.assign after taskstoissues creates one GitHub Milestone per top-level task group in tasks.md
- [ ] Each issue created by taskstoissues is assigned to its corresponding milestone
- [ ] Existing milestones with matching titles are reused, not duplicated
- [ ] Optional milestones-config.yml allows custom grouping by task ID pattern
- [ ] The extension installs via specify extension add milestones
- [ ] The after_taskstoissues hook fires with a confirmation prompt
- [ ] Documentation covers default and custom grouping modes
- [ ] Works with all supported agents

### Additional Context

The grouping data already exists in tasks.md. Tasks are organised under headings that correspond to user stories or feature areas. The extension maps each heading to a GitHub Milestone. No new task structure or metadata format is required. This closes the gap between task-level tracking (issues) and delivery-level tracking (milestones) within the existing SDD workflow.

Start by tracing the existing /speckit.taskstoissues flow and its after_taskstoissues hook, then inspect the extension manifest shape and commands/assign.md entry point. Use tasks.md headings as the default grouping and review the proposed .specify/milestones-config.yml mapping. Done means the acceptance criteria are met, including milestone reuse, installation, confirmation, documentation, and support for all agents.

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