release: let npm authenticate itself instead of a placeholder token

[viict]

The npm job of the v0.4.0 release failed. The crate published fine.

npm notice publish Signed provenance statement … published to transparency log
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/@viict%2ftread
npm error 404  … could not be found or you do not have permission to access it.

A 404 on PUT is npm's "not authorized" — it answers 404 rather than 403 so it
does not leak whether a package exists. The cause is in the job's own env:

NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX

actions/setup-node's registry-url writes an .npmrc containing
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN} and sets that variable to a
placeholder when no token is supplied, so npm authenticated with the literal
string. A token in that file also takes precedence over the OIDC exchange, which
is the one thing trusted publishing exists to do — so registry-url is not
merely unnecessary here, it is what breaks it.

Provenance signed correctly because that needs only id-token: write, which is
why the failure surfaced after the statement had been pushed to the
transparency log.

The fix

• Drop registry-url, so no .npmrc is written and npm asks for its own
  credential. registry.npmjs.org is the default; nothing needs to name it.
• Add npm whoami after the upgrade, so a missing or wrong credential fails
  before a provenance statement is signed and logged, rather than after.

Before this can work

Trusted publishing has to be configured for @viict/tread on npmjs.com — repo
viict/tread, workflow release.yml, environment Packaging. If it is not,
npm whoami now says so immediately instead of the publish dying at the last
step.

v0.4.0 still needs publishing to npm by hand: a tag runs the workflow as it
existed at the commit it points at, so this fix takes effect from the next tag.