ci: declare contents:read on Linux build workflow

[arpitjain099]

Adds a workflow-level permissions: contents: read block. The build job checks out the repository (including submodules), installs the toolchain, then invokes cmake and the platform-native build to produce binaries. None of those steps call a GitHub API beyond the initial checkout.

The runtime supply-chain threat that this caps is the one CVE-2025-30066 (the March 2025 tj-actions/changed-files compromise) demonstrated. A tampered third-party action exfiltrates GITHUB_TOKEN from workflow logs and the leaked token retains whatever scope was issued at the workflow level. With contents: read declared in-file, any action - present or future - that runs in this workflow is bounded to read access, regardless of whatever the org default is set to. OpenSSF Scorecard's Token-Permissions check only credits the explicit per-workflow declaration.

YAML validated locally with yaml.safe_load.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[slabko]

Hi @arpitjain099, although we do not use tj-actions/changed-files or any other similar actions, this is indeed a good hardening change. Can you please sign the CLA before I can merge it.