[Feature]: Remove taskstoissues from the core command set

先从 issue 中提到的核心命令模板、命令清单、集成脚手架以及生成命令的预期开始。然后检查特定于 agent 的声明，以及集成、preset 和扩展测试，查找 taskstoissues 始终已安装这一假设。完成的标准是：全新项目中不包含核心命令，github-issues 扩展仍是规范实现，兼容性和 hooks 得到安全处理，并且迁移文档已更新。

Problem Statement

After the bundled GitHub Issues extension is available and the core /speckit.taskstoissues command has completed a deprecation period, retaining both implementations leaves GitHub-specific project-management behavior in the core SDD command set and creates duplicate maintenance surfaces.

The final migration stage should make the extension the sole owner of GitHub issue creation.

Proposed Solution

After #4421 and #4422 have shipped in earlier minor releases, remove taskstoissues from the core command set.

The removal should cover all core-owned surfaces, including:

• The core command template.
• Core command inventories, ordering, and descriptions.
• Integration scaffolding and generated core command expectations.
• Agent-specific argument descriptions and tool declarations.
• Tests that assume taskstoissues is always installed as a core command.
• README, installation, integration, and upgrade documentation.

The bundled github-issues extension should become the sole implementation and continue to provide speckit.github-issues.taskstoissues.

Once the core namespace is free, add speckit.taskstoissues as a deprecated compatibility alias in the extension if the extension command and alias validation rules support it safely. The namespaced command remains canonical. Projects without the extension should no longer receive any tasks-to-issues command.

Document the breaking change prominently and provide an agent-consumable migration recipe:

specify extension add github-issues
specify integration upgrade <integration>

The exact refresh command should be verified against the supported upgrade flow before publication.

Alternatives Considered

• Retain the deprecated core command indefinitely: Leaves provider-specific functionality and duplicate maintenance in core.
• Auto-install the extension for everyone: Preserves behavior but defeats the goal of making issue tracking opt-in.
• Remove the core command without a compatibility alias: Simpler, but unnecessarily disrupts users who have installed the replacement extension and still invoke the legacy name.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

All agents

Use Cases

1. New projects receive only the core SDD workflow unless they explicitly opt into GitHub issue tracking.
2. GitHub issue functionality can evolve and release independently as an extension.
3. Other issue-tracker providers can offer parallel extensions without replacing a core command.

Acceptance Criteria

• This issue is implemented only after #4421 and #4422 have shipped in earlier minor releases.
• taskstoissues is removed from the core command templates and inventories.
• Fresh projects do not receive a tasks-to-issues command unless github-issues is installed.
• The extension remains installable and provides the canonical speckit.github-issues.taskstoissues command.
• A deprecated speckit.taskstoissues extension alias is provided if it can be registered safely after the core command is removed.
• Extension hooks using before_taskstoissues and after_taskstoissues continue to function when the extension command runs.
• Integration, preset, and extension tests are updated for the new opt-in behavior.
• Upgrade documentation clearly identifies the removal as breaking and provides migration commands.
• Related work, including #4370 and #2223, references the extension rather than the removed core command.
• The removal is included in a later minor release.

Additional Context

This is stage 3 of the migration:

1. #4421 adds the bundled GitHub Issues extension.
2. #4422 deprecates the core command after the replacement ships.
3. This issue removes the command from core after the deprecation window.

Spec Kit's current release guidance treats the version as a release identifier rather than a promise that breaking changes require a new major version. The removal may therefore ship in a minor release, provided it is clearly identified and documented as breaking.

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