ci: publish the tagged tree, not the branch tip

[yoheimuta]

Follow-up to #561, needed before v0.57.0 can actually be published (#557).

The bug

Merging #561 and #562 moved master past v0.57.0, and that alone breaks the publish job. Reproduced by replaying exactly what actions/checkout@v6 does with the current settings (fetch-depth defaulting to 1, fetch-tags: true) against today's master:

HEAD: 630f68e Merge pull request #561 from yoheimuta/ci/npm-trusted-publishing
tags present: 122  (v0.57.0? v0.57.0)
git describe --tags --abbrev=0 => fatal: No tags can describe '630f68e...'

npm error command git --no-replace-objects describe --tags --abbrev=0 --match=*.*.*
npm error fatal: No tags can describe '630f68e...'

fetch-tags brings the tag ref down, but a depth-1 clone has no commits connecting HEAD to it, so git describe cannot walk back. This never surfaced before only because every previous release ran while the tag still sat on the branch tip.

There is a second, quieter problem: even when describe does resolve, the job packs whatever tree is checked out. On a workflow_run trigger that is the default branch, not the tag — so master content could go out labelled with the tag's version.

The fix

• fetch-depth: 0 so the tag is reachable
• check the tag out explicitly before packing, so the tarball is the tagged tree

Verified against a full clone of current master: the tag resolves to v0.57.0, npm version from-git yields 0.57.0, and git diff v0.57.0 HEAD -- bdist/js is empty, so the tree published is the released one.

fetch-tags is dropped as fetch-depth: 0 already fetches tags.

The workflow filename is unchanged, so the trusted publisher registration on npmjs.com still matches.

🤖 Generated with Claude Code