Consider Jira issue creation as a preset rather than extension

## Summary

The current community Jira integration ([spec-kit-jira](https://github.com/mbachorik/spec-kit-jira)) is implemented as an extension, which means it provides a parallel command (`speckit.jira.specstoissues`) rather than replacing the core `speckit.taskstoissues`. This creates friction for Jira-using teams since the natural workflow path remains hardcoded to GitHub Issues.

## Problem

The core `speckit.taskstoissues` command:
- Checks that the git remote is a GitHub URL
- Explicitly refuses to proceed for non-GitHub remotes
- Uses GitHub MCP tools to create issues

For Jira teams, this means:
1. The natural `/speckit.taskstoissues` command is unusable
2. Users must remember to use `/speckit.jira.specstoissues` instead
3. The extension **cannot** alias itself as `speckit.taskstoissues` due to extension naming rules requiring the `speckit.{ext-id}.{command}` prefix ([spec-kit-jira#2](https://github.com/mbachorik/spec-kit-jira/issues/2))

## Proposal

Issue tracking provider selection (GitHub Issues vs Jira vs Linear etc.) is a core workflow decision, not an additive feature. The preset system was designed exactly for this — overriding core commands with alternate implementations.

A Jira **preset** could override `speckit.taskstoissues` so that `/speckit.taskstoissues` creates Jira epics/stories/tasks instead of GitHub issues. This keeps the natural workflow intact.

The ideal architecture would be:
| Layer | Purpose |
|---|---|
| **Preset** | Overrides `speckit.taskstoissues` to target Jira |
| **Extension** (existing) | Provides supplementary Jira-specific commands (`discover-fields`, `sync-status`) |

This pattern would also apply to other issue trackers (Linear, Azure DevOps, etc.) — each would provide a preset to swap the core issue creation path.

## Questions

- Is this the intended use of presets, or is there a different recommended approach for swapping issue tracking providers?
- Should the preset catalog include "issue tracker" presets as a category?
- Would it make sense for the existing `spec-kit-jira` extension to also ship a preset component, or should these remain separate?