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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.