Publish Fragment runs deploy-kit at its own pinned version

Parent

Publish Fragment runs deploy-kit at a version this repository pins, so no calling repository carries a package.json, lockfile or .npmrc for it.

The workflow installs @jorisjonkers-dev/deploy-kit from a lockfile in this repository (pinned exactly, 0.14.0 today, beside the existing tools/deploy-check pattern) and runs it with npx --no-install.
The toolkit-directory input is removed. Callers pin the workflow by SHA, so none breaks until it bumps; the change is breaking and released as feat!:.
The run prints the installed deploy-kit version, so a release's log shows which toolkit packed its fragment.
A Renovate bump of that pin cuts a release of this repository (a chore(deps) commit does not today), so callers receive it through their own workflow-ref bumps.
The shared pin never moves ahead of the Estate repository's composition pin: composition refuses a fragment whose minor is newer than its own toolkit's. Both sit at 0.14.0 today; the Renovate rule keeps them grouped or ordered.

Decision recorded in JorisJonkers-dev/deploy-kit (ADR 0089, rewritten by the blocking ticket).

No toolkit-directory input; the install reads only this repository's lockfile
The run log names the installed deploy-kit version
A test covers the install step (version printed, command present)
Renovate configuration makes a deploy-kit pin bump releasable and keeps it from overtaking the Estate's pin
README describes the new contract
A release containing the change exists, read back by its tag