CI/CD: Cache C client build

[juliannguyen4]

Build C client in a separate job, then save shared library as Github artifact
Then pass artifact to job that builds Python client

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.37%. Comparing base (34c2e3f) to head (d400d49).
⚠️ Report is 4 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #764      +/-   ##
==========================================
+ Coverage   82.35%   82.37%   +0.02%     
==========================================
  Files          99       99              
  Lines       14379    14509     +130     
==========================================
+ Hits        11842    11952     +110     
- Misses       2537     2557      +20     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

To fix the problem, you should add a permissions block to the workflow file, specifying the minimum set of permissions needed for the job to operate. Since this workflow only checks out code and interacts with artifacts, the minimal required permission is typically contents: read. If the workflow also uses actions that require managing workflow metadata, adding actions: read is recommended, but contents: read is the absolutely necessary minimum for code checkout. You can place the permissions block either at the workflow root (to apply to all jobs by default) or within the specific job (to scope it only to that job). In this case, placing it at the root is both concise and clear. There is no need to change any imports or other job steps.

Specifically, insert the following block near the top of .github/workflows/build-python-client.yml:

permissions:
  contents: read

This should be placed after the on: block and before the jobs: block.

To fix this issue, set an explicit permissions block at the root of .github/workflows/build.yml, to minimize the GITHUB_TOKEN's privileges for all jobs unless specifically overridden. If neither job needs to make any changes to code, releases, issues, etc., the strictest permission is contents: read, which allows jobs to clone code but not write to the repository. Add the following block to the top-level of the workflow (just beneath the workflow name: if present, or beneath the on: block, before jobs:), so that all jobs inherit these permissions unless overridden in reusable workflows.

Steps:

• Insert a permissions: block at the top level of .github/workflows/build.yml (between on: and jobs:).
• Set contents: read (minimal permission for most build/test workflows).
• If jobs require additional write permissions (e.g., to PRs or issues), amend as needed, but from the code shown, only read is necessary.

To fix the problem, you should add a permissions block to .github/workflows/build.yml, either at the root level (so it applies to all jobs unless overridden) or at the job level for each job. Since both jobs are included via uses (i.e., "reusable" workflows), and as the workflow itself should set a minimal permissions block unless stronger job-specific permissions are required, you should add a root-level permissions key specifying the least privilege needed. If unsure, you can start with the minimal recommended permissions: contents: read, which allows read-only access to repository contents, and further permissions can be added later if features break or more privilege is required. This change should be made near the top of the workflow file, immediately after the on: block.

To fix this issue without changing the existing workflow functionality, add a permissions: block at the top/root of the workflow file (just after on: and before jobs:). The minimal set required here is likely contents: read since the workflow only reads repository content, checks out code, and uploads/downloads artifacts. None of the steps require elevated write privileges. Thus, set permissions: contents: read at the root, which will apply to all jobs (unless overridden at job level). No imports or method definitions are necessary.

Changes to make:

• Insert the following block after the on: section and before jobs: (i.e., between lines 3 and 4):

permissions:
  contents: read

---