ci: re-register star history schedule

[av1155]

Summary

The star history workflow has never run on its schedule. Two runs exist, both
manual dispatches on 6 August; filtering its runs on event=schedule returns
zero. The chart is still the seeded one at 262 stars against 264 today.

The file landed on main at 18:48 UTC on 6 August, inside the Actions incident
that ran 15:22 UTC that day to 02:04 UTC the next
(https://stspg.io/rcz3fcm83sff). That incident's closing note says
workflow-triggering events in the window were not processed and cannot be
replayed, and that the triggering action needs repeating with a new commit. A
schedule is registered off the default-branch push that introduces it, so this
one never registered. The only later push to main, b06cd4f at 20:22 UTC, was
also inside the window with webhooks throttled to roughly 15%, so the usual
resync did not happen either.

The workflow is active, the file is on main, the cron is valid, Actions are
enabled, and the other seven scheduled workflows all fire, so the registration
is the only thing missing. Merging this is what re-registers it.

Closes #721

Changes

• Move the cron from 07:23 to 07:41 UTC. The minute itself does not matter; a
  changed schedule guarantees the parsed definition differs from whatever is
  cached, and the push is what triggers the resync.
• Add watch: types: [started], so starring the repo refreshes the chart
  instead of leaving it to wait out the day. The cron stays as the backstop
  because started is the only activity type watch has, so unstarring never
  reaches it. Any GitHub account can trigger this, which is fine here: no event
  payload value reaches the job, which reads stargazers from the API, renders
  with a script in this repo, and writes two SVGs to the unprotected assets
  branch.
• Set cancel-in-progress: true. Each run rebuilds from the full stargazer
  list, so a newer run supersedes an older one and a rush of stars no longer
  queues one serial run each.

Testing

actionlint is clean on the changed file and the SHA pin check passes. No
Python changed.

Worth flagging for whoever merges: the commit and force-push half of the publish
step has never executed, since both earlier runs hit the "chart unchanged" early
exit. Simulating it against a shallow clone of assets shows the pieces are
sound, the remote-tracking ref --force-with-lease needs is there and the seed
commit is a parentless orphan so amending it raises no shallow-update problem,
but the first run after merge is the real proof. The live count differs from the
published one, so a manual dispatch will exercise it: the assets tip message
should change from chore: seed star history chart assets to chore: refresh star history chart and the chart should report 264.

Whether the cron itself comes back only shows up over the next day or two. If no
scheduled run appears within two windows, the next step is renaming the workflow
file, then GitHub Support.

Type of Change

• Bug fix (fix:)
• New feature (feat:)
• Refactoring (refactor:)
• Documentation (docs:)
• CI/CD (ci:)
• Chore (chore:)

Checklist

• Issue exists and is linked above with Closes #N
• Linked issue has exactly one type:* and one priority:* label
• Linked issue has at most one phase:* label (or none when not roadmap work)
• Branch name matches issue scope (feat/<slug>, fix/<slug>, etc.)
• Tests added/updated for all changes — N/A, workflow trigger config only
• Type check passes (mypy src/) — N/A, no Python changed
• Lint passes (ruff check .) — N/A, no Python changed
• Format passes (ruff format --check .) — N/A, no Python changed
• Documentation updated (if applicable) — N/A
• No secrets or sensitive data committed
• Scope check: This change helps search for missing or cutoff-unmet media in a controlled way — N/A, repo tooling