Plugin signatures cover plugin.yaml but not the artifacts it downloads and runs #838

Split out of #816 / GHSA-54x4-pc23-4m6j (remediation item 3), because unlike the rest of
that advisory it cannot be fixed in this repo alone and would break every official
plugin install if shipped as-is.

The gap

Signature verification covers plugin.yaml — the manifest hashes the spec and the
signature covers the manifest. It says nothing about the artifacts the spec then fetches
and executes as root.

Step.SHA256 exists and is optional: pkg/plugin/validate.go checks its format when
present, and nothing requires presence. So a signed, verified spec can download an
unpinned binary over the network and run it, and every verification step in front of that
is satisfied.

Why it can't just be enforced

The live official plugins declare no checksums at all. Measured against
spore-host/spore-plugins@main:

So requiring Step.SHA256 for official plugins today turns every official install into a
validation error. The registry has to be updated first.

Order of work

1. spore-plugins: add sha256 to every step that fetches an artifact, and publish new
   per-plugin releases. (Note spore-host-plugin-rstudio and -spore-sync are stale forks
   per spore-plugins#26 — worth resolving first so checksums are added once, to the live
   source.)
2. spawn: require Step.SHA256 for host: official specs, with a gate that fails if
   an official spec omits it.
3. Decide what third-party (github:) specs must do. They are already warned about as
   unverified, so requiring checksums there may be the wrong trade — but it should be a
   decision, not an omission.

Not urgent in the same way as #816

#816 was reachable by the most natural install form and is fixed. This one needs an
attacker who can already serve different bytes at a URL a signed spec names — real, but a
step further along, and the registry currently pins artifacts by URL rather than by
content.