feat: sync issue template tags/categories from scripts.json

[pfeerick]

Summary

• category and tags were hardcoded in four separate places (validate_scripts.py, issue_to_scripts.py, and both issue form templates) and had already drifted once (e.g. the battery checkbox was added to only one template). scripts.schema.json is now the single canonical source, with tools/sync_issue_template_options.py regenerating both templates' marker-bounded option blocks and the schema's examples fields from actual usage in scripts.json.
• Tags are a pure usage snapshot (a tag that stops being used drops out on the next sync). Categories are monotonic add-only — they drive the gallery's top-level nav tabs, so one hitting zero current entries is never auto-pruned by default, only flagged via an unused_categories CI notice. A new --prune-categories flag lets a maintainer deliberately remove currently-unused categories on demand (--check --prune-categories to preview, --write --prune-categories to apply), rather than requiring a hand-edit of the schema JSON.
• Both issue templates gain a free-text "New Category" field (mirroring "Additional Tags"), since the dropdown previously had no way to introduce a new value — issue_to_scripts.py no longer hard-rejects unrecognized categories.
• .vscode/settings.json associates scripts.schema.json for editor-time validation/autocomplete on scripts.json.
• Tags/categories sort case-insensitively (str.casefold) so e.g. "Games & Fun" sorts before "GPS & Mapping" as a human would expect, rather than plain ASCII order.

CI (validate-issue-templates.yml)

• check (PRs): read-only --check, gates on drift.
• sync (push): self-heals same-repo branches by running --write and committing the correction back — this is what lands the fix directly in the PR that introduced a new tag/category, including direct-edit PRs that never went through an issue form. Uses GITHUB_TOKEN, so it can't push to forks and (deliberately) can't trigger further workflow runs, avoiding recursion.
• suggest-fix-for-fork-prs (pull_request_target, fork PRs only): GITHUB_TOKEN can never push to a fork under any trigger, so instead this safely computes the same fix (checks out the base branch's trusted script, only ever treats the PR's scripts.json as inert data, never executes anything from the fork) and posts it as a sticky PR comment with both resolution paths — a maintainer pulling the branch in, or running --write locally and committing it.
• All four workflows in the repo (including the three pre-existing ones, not just this PR's new one) have enable-cache: false added to their setup-uv steps — there's no lock/requirements file for uv to key a cache on, so it was warning that the cache could never invalidate.

Test plan

• uv run tools/test_sync_issue_template_options.py — 10 unit tests covering multi-region splicing, monotonic category retention vs. tag pruning, --prune-categories, drift detection, and idempotency
• uv run tools/validate_scripts.py --scripts-json scripts.json — 58 entries valid, no new errors
• uv run tools/sync_issue_template_options.py --check — in sync
• issue_to_scripts.py fixture runs: dropdown-only, free-text-only, both (free text wins), neither (correctly rejected)
• YAML/JSON validity of all new/changed files
• Live verification of the pull_request_target sticky-comment job against a real fork PR (can't be simulated locally)

🤖 Generated with Claude Code