cc-release-watch — workflow_dispatch re-registration fix

Why a one-line YAML change unblocks the smoke-test path.

Symptom

POST repos/{owner}/{repo}/actions/workflows/259675442/dispatches
HTTP 422: Workflow does not have 'workflow_dispatch' trigger
Returned even though the file on main clearly has workflow_dispatch: in its on: block.

Root cause

2026-04-12
cc-release-watch.yml first added with name: CC Release Watch and workflow_dispatch: {} (explicit empty-inputs). GHA registers workflow ID 259675442 but, for unknown reasons, fails to capture the friendly name — registers it as .github/workflows/cc-release-watch.yml (file path) instead.
2026-05-02
M130 PR #1589 replaces the file content. New name: cc-release-watch, new schedule, new triggers — and switches to the implicit form workflow_dispatch:. GHA does NOT re-parse metadata for this workflow ID; the cached "no friendly name + no dispatch trigger" state persists.
2026-05-02
Hotfix PR #1591 lands without touching the trigger syntax. Dispatch attempts return 422.
GitHub Actions caches workflow metadata at registration time and doesn't always invalidate on file content changes. The implicit workflow_dispatch: form (valid YAML, equivalent to workflow_dispatch: {}) appears to be a trigger for this cache-coherency edge case.

Fix

.github/workflows/cc-release-watch.yml
on:
  schedule:
    - cron: '0 14 * * *'
  workflow_dispatch:
on:
  schedule:
    - cron: '0 14 * * *'
  workflow_dispatch: {}
Explicit empty-inputs form. Forces GHA to re-parse the file's trigger block, which re-registers workflow_dispatch as available. No semantic change — both forms accept zero inputs.

Verification path

  1. This PR merges to main.
  2. The merge commit forces GHA to re-index cc-release-watch.yml.
  3. gh workflow run cc-release-watch.yml succeeds (returns a run URL).
  4. The dispatched run executes end-to-end with CLAUDE_CODE_OAUTH_TOKEN configured: snapshot → triage (LLM) → issue creation, no fallback issue filed.
If step 3 still 422s, the next mitigation is to rename the workflow file (e.g., cc-watch.yml) to force a brand-new workflow ID with fresh metadata. Documented as a follow-up in the PR body.

Why not just wait for the daily cron?

14:00 UTC daily would fire on the registered schedule trigger. But if GHA's metadata cache is broken on this workflow, scheduled triggers may also be silently degraded — the schedule entries are parsed from the same on: block as workflow_dispatch. Re-registering via the explicit form covers both.