Add build CI, remappings validation, and ERC721 Medusa coverage

[nisedo]

Summary

• Build CI workflow: Verifies Foundry and Hardhat compilation for root contracts and all test harnesses (ERC20, ERC721, ERC4626), plus validates that all remappings.txt targets resolve to existing directories
• ERC721 Medusa configs + CI: Adds missing Medusa fuzzing configs and workflow jobs for ERC721 (internal + external), closing the coverage gap where only ERC20 and ERC4626 were tested

Test plan

• All 4 Foundry builds verified locally (forge build at root + 3 test dirs)
• Remappings validation script tested: passes on all current remappings, catches broken ones
• ERC721 Medusa internal config: 34/34 tests passed locally
• ERC721 Medusa external config: 39/39 tests passed locally
• Medusa configs validated as correct JSON, structurally identical to working ERC20 configs
• Contract names in workflow match Solidity source

🤖 Generated with Claude Code

In general, the fix is to add an explicit permissions block that grants only the minimal necessary scopes to the GITHUB_TOKEN. Since this workflow only checks out code and runs build/test commands, it can safely operate with read-only access to repository contents. The simplest and clearest solution is to add a top-level permissions: block (at the root of the workflow, alongside name and on) with contents: read, which will apply to all jobs in this workflow.

Concretely, edit .github/workflows/build.yaml and insert:

permissions:
  contents: read

between the name: Build line and the on: block (lines 1–3 in the given snippet). This will not change any existing behavior of the jobs, since actions/checkout and the other actions used only require read access to repository contents. No other lines or jobs need individual permissions blocks unless you later introduce steps that require additional scopes.

In general, fix this by explicitly declaring a minimal permissions block in the workflow, either at the top level (applies to all jobs) or per job, granting only what is needed (here, read access to contents). This ensures the GITHUB_TOKEN cannot be used with broader write permissions, even if repository defaults are permissive.

The best minimal fix without changing existing functionality is to add a root-level permissions block right after the name: Build line, setting contents: read. All the jobs (validate-remappings, foundry-root, foundry-tests, hardhat-root, and any elided ones like hardhat-tests) only need to check out code and run commands; they do not perform write operations against the GitHub API. No extra imports or dependencies are required; it is a pure YAML modification.

Concretely, edit .github/workflows/build.yaml near the top: insert

permissions:
  contents: read

between line 1 (name: Build) and line 3 (on:). This will satisfy CodeQL’s requirement and lock GITHUB_TOKEN down to read-only repository contents for all jobs that do not override permissions. No other regions/lines need to change.

To fix the problem, explicitly declare restricted GITHUB_TOKEN permissions in the workflow. Since all jobs just check out code and build/test, they only require read access to repository contents. The simplest and safest fix is to add a root‑level permissions block (so it applies to all jobs that don’t override it) with contents: read. This avoids changing any existing behavior of the build/test steps while ensuring the token cannot perform write operations.

Concretely, in .github/workflows/build.yaml, add:

permissions:
  contents: read

immediately after the name: Build line (line 1) and before the on: block (line 3). This will satisfy CodeQL’s requirement for explicit minimal permissions and apply uniformly to validate-remappings, foundry-root, foundry-tests, hardhat-root, and any other jobs in this workflow. No additional imports, methods, or other definitions are needed.

To fix this, explicitly restrict the GITHUB_TOKEN permissions used by this workflow to the minimal scope needed. All jobs here only read the repository contents (via actions/checkout and subsequent builds), and do not push changes, create releases, or modify issues/PRs. The least-privilege configuration is to set permissions: contents: read. The cleanest way without changing behavior is to add a single permissions: block at the workflow root (top level), so it applies to all jobs that do not override it.

Concretely, in .github/workflows/build.yaml, add a top-level permissions: section between the name: and on: keys (around lines 1–3). Use:

permissions:
  contents: read

This leaves all job logic unchanged while ensuring that the GITHUB_TOKEN has read-only access to repository contents for all jobs, including hardhat-root. No additional methods, imports, or definitions are needed because this is purely a YAML configuration change.

To fix the problem, explicitly set minimal GITHUB_TOKEN permissions for the workflow. The simplest and best approach without changing existing functionality is to add a top-level permissions block applying to all jobs. Since all jobs just check out code and run builds/tests, they only need read access to repository contents, so contents: read is sufficient.

Concretely, in .github/workflows/build.yaml, add a root-level permissions section after the name: Build line and before the on: block:

• Add:

  permissions:
    contents: read

This will restrict the token for all jobs (validate-remappings, foundry-root, foundry-tests, hardhat-root, hardhat-tests) to read-only access to repository contents, resolving the CodeQL finding while preserving current behavior.