fix(setup): remove registry-url — it served nobody and invited a harmful config

[usetheodev]

Corrects #54, which I opened, justified and merged an hour ago on a false premise.

The premise, and why it was false

#54 said: "seven of the nine release.yml pass registry-url, so adopting the shared setup
meant losing npm authentication".

That number came from grep -c registry-url. Where registry-url appears in those workflows is
inside a comment explaining why it is deliberately absent:

"NO registry-url. It looks harmless and is not: setup-node writes
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN} into an npmrc UNCONDITIONALLY and points
NPM_CONFIG_USERCONFIG at it, then exports NODE_AUTH_TOKEN only if the caller supplied one —
which, under OIDC, nobody does. The job would publish with a config declaring a credential that
does not exist."

Measured by matching the YAML key rather than the string:

registry-url as a key      : 0 of 9
mentioned in a comment     : 7 of 9
publishing through OIDC    : 9 of 9

So the input served nobody, and its docstring — "a publishing job needs it" — invited the exact
configuration this ecosystem had already found, understood, and written down as harmful. An unused
input is inert; an unused input with confident wrong documentation is a trap for the next person
converting a release workflow.

What this does

Removes the input and the passthrough. The reasoning moves next to the setup-node call so the
absence reads as a decision rather than an oversight, and the CI job asserts the opposite
property: that the action writes no _authToken npmrc on a caller's behalf.

What survives the correction

The finding that prompted #54 is unaffected and still the largest duplication here:

workflows setting up node/pnpm : 22
using actions/setup@v1         :  1 file

The difference is that the blocker I described never existed. The action was a drop-in for
release.yml all along — nothing had to be added first, and the twenty conversions can proceed
against @v1 as it stood before #54.