[Feature]: Add parallelizable task planning to Spec Kit workflows

### Problem Statement

## What's missing

`/speckit.tasks` produces a mostly linear checklist today. It's clear, but it never says which tasks are actually independent of each other.

In larger features, plenty of tasks don't depend on anything — docs, an isolated UI change, backend validation, a separate integration point. Right now you have to read the whole list and work out yourself what's safe to split across worktrees, branches, or sessions. That guesswork quietly pushes everything into sequential execution even when it didn't need to be.

### Proposed Solution

## Idea

Have task generation mark dependencies and parallelizable groups — either as a new command, `/speckit.parallel-plan`, or as an optional section in `/speckit.tasks`.

Inline annotations per task:

```markdown
- [ ] T001 Create database migration for user preferences
- Depends on: none
- Parallel with: T003, T004

- [ ] T002 Add preferences API endpoint
- Depends on: T001
```

…and/or a wave-based plan:

```markdown
## Parallel execution plan

### Wave 1 — start immediately, separate worktrees
- T001 Create database migration
- T003 Add frontend settings form
- T004 Update docs

### Wave 2 — after Wave 1
- T002 Add preferences API endpoint
- T005 Add integration tests
```

## Why it helps

- Cuts total implementation time on bigger features
- Lets AI agents work in parallel sessions/worktrees without colliding
- Makes dependencies and merge boundaries explicit
- Nudges toward smaller, independently mergeable slices
- It's just planning info — it doesn't force parallel execution

## Rough approach

Update the task-generation prompt to ask for dependencies, independent groups, execution waves, and which tasks are safe in separate worktrees. Keep output backwards-compatible with existing task lists, and don't mark tasks parallel if they touch the same files or hinge on the same unresolved design decision.

On naming, I'd lean toward `/speckit.parallel-plan` — it reads as an execution plan rather than a task mutation, and avoids spelling ambiguity. Alternatives: `/speckit.parallel-tasks`, `/speckit.task-graph`, `/speckit.execution-plan`.

---

*AI disclosure: I used AI to help shape and draft this issue; the idea and final wording are mine.*

### Alternatives Considered

_No response_

### Component

Specify CLI (initialization, commands)

### AI Agent (if applicable)

None

### Use Cases

1. Large features where many tasks are actually independent (docs, an isolated UI change, backend validation, tests) and could safely be worked at the same time.
2. Driving multiple AI agents — or your own multiple sessions — across separate git worktrees in parallel, without them colliding on the same files.
3. Reviewers and contributors who need to see at a glance which changes are independent and where the safe merge boundaries are.

### Acceptance Criteria

- [ ] Task generation can annotate each task with its dependencies
- [ ] Independent tasks are grouped into parallel execution waves
- [ ] Output stays backwards-compatible with existing `/speckit.tasks` lists
- [ ] Tasks that touch the same files or share an unresolved design decision are never marked parallel
- [ ] Documentation is updated
- [ ] Works across all supported agents

### Additional Context

This is planning information only — it surfaces dependencies and parallelizable groups, it doesn't force parallel execution. Naming preference is `/speckit.parallel-plan` (reads as an execution plan rather than a task mutation); alternatives considered: `/speckit.parallel-tasks`, `/speckit.task-graph`, `/speckit.execution-plan`.

Start with the existing /speckit.tasks entry point and the task-generation prompt. Trace how task lists are produced across all supported agents, then define a backwards-compatible representation for dependencies and execution waves. Done means independent tasks are grouped safely, shared files or unresolved decisions prevent parallel marking, documentation is updated, and existing task lists still work.

Rédigé par le modèle d'indexation à partir du texte de l'issue.