[Feature]: Add a bundled `github` extension for taskstoissues

### Problem Statement

`/speckit.taskstoissues` creates GitHub issues from `tasks.md`, but GitHub issue tracking is provider-specific project-management functionality rather than part of the core Spec-Driven Development lifecycle.

Before the core command can be deprecated or removed, users need a fully functional extension-based replacement with an explicit installation and migration path.

### Proposed Solution

Add a bundled, opt-in `github-issues` extension that provides the existing tasks-to-issues behavior under a namespaced command:

```bash
specify extension add github-issues
/speckit.github-issues.taskstoissues
```

Proposed manifest shape:

```yaml
schema_version: "1.0"
extension:
id: github-issues
name: "GitHub Issues"
version: "1.0.0"
description: "Create GitHub issues from Spec Kit task lists"

provides:
commands:
- name: speckit.github-issues.taskstoissues
file: commands/speckit.github-issues.taskstoissues.md
description: "Convert tasks from tasks.md into dependency-ordered GitHub issues"
```

The extension command should preserve the current behavior:

- Resolve the active feature and load `tasks.md`.
- Confirm that the repository remote points to GitHub.
- Detect existing issues by task ID across open and closed issues.
- Create only missing issues in the repository identified by the remote.
- Preserve the `before_taskstoissues` and `after_taskstoissues` hook contract.
- Work across all supported integrations, including skills-based layouts.

The existing core `/speckit.taskstoissues` command must remain unchanged in this stage. The extension must not claim that legacy alias while the core command still exists.

### Alternatives Considered

- **Deprecate the core command first:** Rejected because users would receive a warning without having a working replacement.
- **Move the command immediately:** Rejected because it would combine replacement, deprecation, and removal into one migration step.
- **Use a generic `issues` extension:** A provider-specific extension makes GitHub tooling requirements explicit and leaves room for Jira, Linear, and other providers.

### Component

Specify CLI (initialization, commands)

### AI Agent (if applicable)

All agents

### Use Cases

1. Users can opt into GitHub issue creation without adding provider-specific behavior to the core SDD workflow.
2. Extensions such as milestone grouping can declare a dependency on the namespaced GitHub Issues command.
3. Alternative issue-tracker extensions can coexist without replacing a core GitHub-specific command.

### Acceptance Criteria

- [ ] A bundled `github-issues` extension can be installed with `specify extension add github-issues`.
- [ ] The extension provides `speckit.github-issues.taskstoissues` for every supported integration.
- [ ] The extension preserves current issue creation, remote validation, pagination, and deduplication behavior.
- [ ] Existing `before_taskstoissues` and `after_taskstoissues` hooks execute as before.
- [ ] The core `speckit.taskstoissues` command remains available and unchanged.
- [ ] The extension does not register a legacy alias that conflicts with the core command.
- [ ] Extension-specific tests cover installation, invocation artifacts, hooks, and uninstall behavior.
- [ ] Documentation explains installation, usage, and the planned migration from the core command.
- [ ] The change is included in a minor release.

### Additional Context

This is stage 1 of a three-stage migration:

1. Add the extension while retaining the core command.
2. Deprecate the core command after the replacement is available.
3. Remove the command from core in a later minor release.

Related discussion: #4370, especially https://github.com/github/spec-kit/issues/4370#issuecomment-5525946904.

The Jira preset/extension direction in #2223 should also be considered when documenting provider-specific issue-tracker integrations.