build-skills workflow: attestation storage-record warnings + deprecated actions/attest-sbom

Every run of build-skills.yml that publishes a skill artifact logs two warnings during the attestation steps, e.g. run 33443605482:

In "Attest build provenance for skill artifact":

Warning: Failed to create storage record: Error: Failed to persist storage record: no artifacts found - https://docs.github.com/rest/orgs/artifact-metadata#create-artifact-metadata-storage-record
Warning: Please check that the "artifact-metadata:write" permission has been included

And separately:

actions/attest-sbom has been deprecated, please use actions/attest instead

build-containers.yml doesn't hit either warning, even though it also attests container images.

Root cause

build-skills.yml's build-skill-artifacts job calls actions/attest-sbom@v4.1.0 and actions/attest-build-provenance@v4.2.2 directly against the pushed image digest. These actions attempt to create an artifact-metadata "storage record" linking the attestation to a GitHub Actions build artifact, which requires the artifact-metadata: write permission and only succeeds when the subject corresponds to something uploaded via actions/upload-artifact in the run. Our subject is a container image, not a workflow artifact, so the lookup fails — non-fatal, but noisy on every run.

build-containers.yml avoids this entirely: it gets SBOM/provenance via docker/build-push-action's built-in sbom: true / provenance: true (BuildKit attaches these to the manifest directly, no GitHub Attestations API call), and does its own SCAI attestation via cosign attest rather than actions/attest-*.

Proposed fix

• Replace actions/attest-sbom with the unified actions/attest action (addresses the deprecation warning).
• Either add artifact-metadata: write to the job permissions (if we want the storage-record linkage) or investigate whether it can be suppressed/skipped for image-only subjects, since there's no corresponding workflow artifact to link to.
• Consider whether build-skills.yml should follow build-containers.yml's pattern more closely if a build tool used there supports native provenance/SBOM generation, to reduce reliance on the actions/attest-* API surface. (dockhand build-skill may not have an equivalent to buildx's built-in attestations — worth checking before committing to this.)

Files: .github/workflows/build-skills.yml (steps "Attest SBOM for skill artifact", "Attest build provenance for skill artifact")

Start with the two attestation steps in .github/workflows/build-skills.yml, then compare them with the attestation pattern in build-containers.yml. Check whether dockhand build-skill supports native provenance or SBOM generation and determine the appropriate artifact-metadata permission or suppression behavior. Done means the workflow uses the supported attestation action or pattern and no longer emits the reported warnings.