feat: publish-fragment workflow and the render-diff step for deploy-kit projects

[ExtraToast]

Summary

Adds the reusable publish-fragment workflow an application repository calls on a release tag, and a render-diff action that comments what a pull request's project-file change does to the Project's render. Both follow deploy-kit's worked workflows (spec/v1/examples/workflows/), and every decision in them is a deploy-kit command.

• publish-fragment.yml, one job:
  • installs the toolkit from the caller's own lockfile (npm ci), and fails with a clear message if the pinned release ships no command;
  • puts an uploaded migration-proof.yml beside the project file when the caller names the artifact;
  • deploy-kit validate, then deploy-kit publish with the release's version, and a per-file manifest;
  • pushes to ghcr.io/<owner>/intent-<project> under the version, signs keyless, pulls back by digest, checks every file against the manifest and verifies the signature;
  • starts compose.yml in the Estate repository with a token minted for the dispatch App.
• latest only moves forward. Publishing an older release again pushes it under its own tag and leaves latest where it is, so a re-run cannot put an earlier fragment in front of composition.
• Signer: the certificate's identity is this workflow, run for the calling repository. Composition can verify every fragment against one subject, …/github-workflows/.github/workflows/publish-fragment.yml@…, and read the repository from the certificate.
• actions/render-diff: packs the project file at the base and at the head, composes the estate once with each in place of the Project's fragment, and diffs the Project's rendered artifact. The report is one comment per Project, replaced on every push. A head that composition would refuse or isolate fails the step, and the comment carries the codes instead of a diff.
• What a pull request controls is held to its shape. The project name is checked before it becomes a path, a pattern or a comment's marker; the diff is fenced with more backticks than anything in it, so a rendered file cannot close the block and continue as Markdown; the marker reaches jq as a value, and only a comment that opens with it is replaced.
• latest fails closed. Only a registry answer of "not found" counts as a first publish. A registry that cannot be read, or a latest with no release on it, stops the run before anything is pushed.
• Tests: 32 new, against a stand-in deploy-kit that records its calls, and stand-ins for oras, cosign and gh: argument passing, the manifest, the forward-only latest, every read-back and verification failure, the diff's shape, and the comment being replaced. The workflow is checked for expressions inside scripts, pinned actions and its permissions. actionlint and shellcheck pass.
• Run against the real command, by hand: pack.sh packed the notes example, and run.sh composed an estate built from deploy-kit's worked examples: a changed memory request gave a two-file diff, an unlocked image gave the refusal with E_UNLOCKED_IMAGE, and an unchanged file reported no change.

To know:

• No release ships the command yet. feat: ship the deploy-kit command in the published package, built when it is packed deploy-kit#237 adds it; it reaches callers with deploy-kit's next release. Until a caller pins that release, the install step fails by design.
• The images-lock share is not packed. The toolkit cannot yet (Pack each project fragment's share of the images lock, and union the shares in composition deploy-kit#230), so the Platform document's fragment still carries the estate's images lock, as the worked workflow says.
• render-diff takes the estate's inputs already pulled. Pulling every participant, the Platform document and the pins is composition's own step, which JorisJonkers-dev/estate#2 builds. The action reads the directory that step leaves, so both use one layout.
• compose.yml on the Estate repository is still the canary, so a dispatch today publishes the canary render.

Part of JorisJonkers-dev/deploy-kit#195 and #135. The ticket stays open for its acceptance line: home-portal publishing through this on a tag.