spectrack: pre-create GitHub issue-type labels at setup and add `issue labels` command

[studykit]

What

When SpecTrack uses GitHub as the issue provider, pre-create the canonical issue-type labels at setup time and record the repository's label set into .spectrack/config.yml, so the first publish/set-type no longer fails on a fresh repo.

Why

Every GitHub issue carries one issue-type label (task, bug, spike, epic, review, usecase, research). GitHub rejects gh issue ... --label <name> when the label does not exist, so on a fresh repo the first publish fails; the only prior recourse was a reactive gh label create hint. Setup should make labels work on first use.

Scope

• Label vocabulary — canonical GITHUB_TYPE_LABEL_SPECS (name/color/description, ordered) in scripts/mustread.py as the single source of truth; _GITHUB_TYPE_LABELS derives from it.
• gh helpers — list_labels / create_label in scripts/issue/github/gh.py.
• Setup — spectrack setup.py ensure-github-labels fetches repo labels, creates missing canonical labels (skip-existing, case-insensitive, never overwrite), and returns the merged set (repo color/description wins on collision). build-config gains --github-label / --github-labels-json to record providers.issues.settings.labels (stays offline).
• Runtime — new GitHub-only spectrack issue labels verb (table + --json, offline config read). _VERB_HELP widened from jira_only: bool to a provider-scope only field.
• Docs/version — skills/setup/SKILL.md flow + rules; Claude/Codex plugin.json bumped 0.16.15 → 0.16.16.

Acceptance Criteria

• Setup with the GitHub issue provider creates missing type labels and skips existing ones (case-insensitive); re-running is a no-op.
• Config records the merged label set under providers.issues.settings.labels.
• spectrack issue labels lists configured labels (and --json) offline; hidden/refused for non-GitHub providers.
• build-config / write remain usable offline.
• Full test suite passes.