Add attested builds for native fbuild artifacts

[zackees]

Summary

fbuild should produce attestations for its native build artifacts so users and downstream CI can verify that downloaded binaries/extensions were built by the expected GitHub Actions workflow from the expected commit/ref.

Current relevant workflow shape:

• .github/workflows/build.yml manually dispatches a platform matrix for native binaries.
• .github/workflows/template_native_build.yml builds and stages:
  • fbuild / fbuild.exe
  • fbuild-daemon / fbuild-daemon.exe
  • _native.abi3.so or _native.pyd
• The staged files are uploaded with actions/upload-artifact@v7 as binaries-${{ inputs.target }}.

Goal

Add GitHub Artifact Attestations / build provenance for the final distributable native artifacts, not just intermediate compiler outputs.

Docs/reference:

• https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds
• https://github.com/actions/attest
• https://github.com/actions/attest-build-provenance

Proposed Work

• Decide the attestation subject boundary:
  • At minimum, attest every file under staging/ before upload.
  • If a later release workflow packages these files into archives/wheels, attest those final archives as well, because those are what users actually download.
• Add required workflow permissions to the native build workflow:
  • contents: read
  • id-token: write
  • attestations: write
• Add an attestation step in .github/workflows/template_native_build.yml after Stage artifacts and before or alongside Upload artifacts.
• Consider adding a SHA256SUMS file to staging/ and include it in the uploaded artifact. This is not a substitute for provenance, but makes manual inspection easier.
• Ensure the attestation includes enough useful provenance to distinguish:
  • target triple (${{ inputs.target }})
  • runner OS / architecture
  • source ref / commit (${{ inputs.ref || github.sha }})
  • workflow name and run ID
• Add verification documentation for consumers, for example:
  • gh attestation verify <downloaded-file> --repo FastLED/fbuild
  • how to verify each binary inside binaries-${target} after downloading a workflow artifact or GitHub Release asset.
• Decide whether attestations should be emitted for all manual build.yml runs, only tag/release builds, or both. A good default is to attest all native build artifacts, then document that release/tag attestations are the trusted distribution path.

Acceptance Criteria

• Native build artifacts uploaded by build.yml have GitHub-hosted provenance attestations.
• A maintainer can download a binaries-${target} artifact and verify each staged file with gh attestation verify against FastLED/fbuild.
• The verification instructions are documented in the repo, ideally near .github/workflows/README.md or release documentation.
• CI remains green across Linux, macOS, and Windows native build targets.

Notes

GitHub's attestation action requires OIDC and attestation write permissions. If this is implemented in a reusable workflow, verify that permissions are granted at the effective job level for the called workflow, not only in the caller.