ci(reward): keep reward tags off Latest and out of git describe

[FenjuFu]

Summary

• What changed? The reward bot now tags a detached empty commit, and the monthly statistic release no longer becomes "Latest".

  • share-reward.ts / count-reward.ts point new reward-* / statistic-* tags at a parentless empty-tree commit, created by .github/scripts/git.ts. The merge commit SHA stays in that commit's message.
  • statistic-* releases are created with --latest=false.
  • statistic-member-reward.yml drops the git describe --match "statistic-*" pre-check, which cannot see detached tags. count-reward.ts already exits when the previous month has no reward data.

• Why is this needed? We hit both problems in iflytek/astron-agent, which uses the same reward scripts (Document the stable release channel and keep reward releases from taking "Latest" astron-agent#1694, fixed in chore: make vX.Y.Z the stable release channel (docs, Helm, reward tags) astron-agent#1695):

  • "Latest" release: gh release create without --latest=false lets the API default (make_latest: true) mark statistic-2026-09 as the repository's Latest release for a week. Anything that resolves releases/latest would have received a reward summary instead of a product release. In skillhub, that would mean losing v0.2.x (or a cli-v* release) as Latest.
  • git describe: tags on product commits become the nearest tag for later commits. In astron-agent, 36 of the last 400 commits on main describe as reward-1575-N-g… / statistic-2026-09-N-g…, compared with 12 as v1.1.1-N-g….

  skillhub has no reward or statistic tags yet, so this change prevents the problem before the first payout. No existing tags need migrating.

Validation

• Backend tests passed
• Frontend typecheck/build passed
• OpenAPI SDK regenerated or checked when API contracts changed
• Smoke test run when relevant

I tested this end-to-end in a sandbox repo with a local bare remote, Deno 2.9 and a fake gh on PATH. The repo had a v1.0.0 tag followed by two more commits.

1. I ran the new tagging and push code from this branch's share-reward.ts (via createDetachedCommit), with a reward dated last month. It created reward-42 on a commit with no parents and the empty tree (4b825dc), and the commit message records the merge SHA.
2. I ran this branch's count-reward.ts unmodified. It found the tag by creator date and produced @bob / CNY RMB: 300. It pushed statistic-2026-10 on a second detached commit and called gh release create statistic-2026-10 --latest=false --notes ….
3. git describe --tags HEAD still returned v1.0.0-2-g…. The remote held all 3 tags, and no git identity was left in the local config.

Risk

• User-facing impact: none. Reward comments, tag contents and statistic releases look the same. Only the commit a reward tag points at changes, and that commit's message keeps the merge SHA.
• Deployment or migration impact: none.
• Rollback approach: revert this commit.

Notes

• Related issue: Document the stable release channel and keep reward releases from taking "Latest" astron-agent#1694
• Follow-up work: none
• Docs or operator runbooks updated when behavior changed: N/A