feat: support installing both PowerShell/Bash script variants

[davengn]

Description

Adds --script both as an opt-in script selection mode for specify init and integration management commands. This lets teams initialize a project with both .specify/scripts/bash/ and .specify/scripts/powershell/ installed, which is useful when developers on the same project use different operating systems.

Generated agent command files still embed one primary script invocation. When both is selected, the primary script is the local OS default: PowerShell on Windows, Bash elsewhere. The selected both value is preserved in project metadata so later integration operations continue installing both variants.

Also updates docs and tests for the new script mode.

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest
• Tested with a sample project (if applicable)

Focused validation run:

python -m pytest tests/integrations/test_cli.py::TestInitIntegrationFlag::test_integration_copilot_script_both_installs_both_variants tests/integrations/test_cli.py::TestInitIntegrationFlag::test_shared_infra_both_records_both_variants_without_overwrite tests/integrations/test_integration_subcommand.py::TestScriptTypeValidation tests/test_agent_config_consistency.py tests/test_commands_package.py -q --basetemp .tmp/pytest

Result: 37 passed

Also ran the broader focused suite for tests/integrations/test_cli.py and tests/integrations/test_integration_subcommand.py; it reached 138 passed, 2 skipped, with 7 existing Windows symlink privilege failures (WinError 1314) before project code executed.

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (describe below)

Implemented with Codex assistance for code changes, tests, docs updates, and PR preparation.

[mnriem]

Thanks for the work here — the selected_script / render_script split is a clean abstraction and the implementation is well-scoped and tested.

However, I don't think this lands the stated goal. {SCRIPT} is resolved at install time for both markdown integrations (in IntegrationBase.setup) and skills integrations (resolve_skill_placeholders is called from install/convert paths, not at agent runtime). So a Windows teammate pulling a repo initialized with --script both on macOS still gets agent commands invoking .specify/scripts/bash/setup-plan.sh. The "mixed-OS team" scenario in the PR description isn't actually solved — only the on-disk presence of both variants is.

Properly fixing this would require either deferring {SCRIPT} resolution to runtime (which spec-kit only has a hook for in skills integrations, not markdown ones), emitting per-command dispatcher shims, or rendering dual command files. Each adds meaningful surface area and ongoing maintenance burden that I don't think is justified given there's a simpler path available today.

For mixed-OS teams, the practical recommendation is to standardize on one shell per repo:

PowerShell 7 (pwsh) — runs natively on macOS/Linux/Windows; use --script ps. Lightest install on non-Windows hosts.
Bash via WSL or Git Bash on Windows — use --script sh. Familiar for teams already Unix-leaning.
Pick whichever your team is more comfortable with and document the choice in the project README.

Going to close this one, but genuinely appreciate the contribution and the discussion it surfaced — the analysis it prompted is useful context for any future cross-OS work.