CI: build-attested-binaries always fails on fork PRs (attestation, not the build)

[RealDiligent]

Summary

build-attested-binaries reports failure on every fork pull request, including ones whose
build is completely clean. The build, the packaging and the bundle all succeed — the job then dies
on its last step, actions/attest@v4:

##[error]Error: missing "id-token" permission. Please add "permissions: id-token: write" to your workflow.

The permission is already declared (.github/workflows/build-attested-binaries.yml, both jobs):

    permissions:
      contents: read
      id-token: write
      attestations: write

GitHub does not grant id-token to a workflow triggered by pull_request from a fork,
regardless of what the permissions: block asks for — the token is read-only for fork events. So
the step cannot succeed there, and no contributor can make it green.

Evidence

Same-repo PRs pass; fork PRs fail, independent of content:

PR	author	fork	build-linux / build-windows	merged
#608	skyrocket2026	no	success / success	yes
#595	fansilas	yes	failure / failure	yes
#597	Paral1995	yes	failure / failure	yes
#598	inference2026	yes	failure / failure	yes
#577	James-CUDA	yes	failure / failure	yes
#582	fansilas	yes	failure / failure	yes

Every merged fork PR in that list merged with both checks red, which is the giveaway that the
signal carries no information today.

For a concrete clean run — #610, log of build-linux:

[100%] Linking CXX executable qwen3_gguf_bench
[100%] Built target qwen3_gguf_bench
...
##[error]Error: missing "id-token" permission.

and build-windows:

qwen3_gguf_bench.vcxproj -> D:\a\sparkinfer\sparkinfer\build\runtime\Release\qwen3_gguf_bench.exe
...
##[error]Error: missing "id-token" permission.

There is exactly one ##[error] in each log, and it is always this one.

Why it is worth fixing

The PR build is the only automated signal that a contributor's CUDA actually compiles for
sm_120 on both toolchains before it reaches the RTX 5090 eval queue. Right now that signal is
permanently red for the fork PRs that make up essentially all contributor traffic, so:

• a genuine compile break looks exactly like the status quo, and gets found later on the eval box
  instead of in CI;
• reviewers and the eval bot have to open the log every time to tell "did not build" from
  "built fine, could not sign".

Attestation itself is only meaningful for the artifacts that actually get published (push to
main and v* tags, which feed the release job) — a fork PR's bundle is thrown away, so there is
nothing to attest.

Suggested change

Skip attestation on pull requests and keep building, e.g. on both Generate artifact attestation
steps:

      - name: Generate artifact attestation
        if: github.event_name != 'pull_request'
        uses: actions/attest@v4
        with:
          subject-path: "${{ env.BUNDLE }}/**/*"

Push and tag runs keep signing exactly as today, and PR runs go green iff the code compiles and
packages. continue-on-error: true on that step would also work but leaves a yellow/annotated
step; the if: reads as the intent ("we sign what we publish").

Happy to prepare the patch, but .github/ is maintainer-owned per CONTRIBUTING, so raising it
here rather than as a PR.