Add the ZoneX CI workflows

[fdesbiens]

ZoneX has no .github/workflows/. Nothing gates a pull request today.

Blocked by #3, which provides the scripts the regression workflow calls.

Scope

Mirror the workflow set the other repositories run, adapted to ZoneX:

• Compiler checks on the reference toolchains — GCC (Arm GNU Toolchain 14.3.rel1) and LLVM (ATfE 22.1.0), as gcc_check.yml and clang_check.yml do. Fetch each toolchain from its published release, verify the checksum, and cache it, rather than depending on a third-party setup action.
• Regression suite with coverage, as a reusable workflow_call template plus a caller, following regression_template.yml / regression_test.yml. Coverage thresholds per the decision in Decide the host target for the ZoneX regression suite #2.
• Port checks, once ZoneX has more than one port.

Requirements

• Triggers are pull_request against dev and main, and push to dev and main. Getting this wrong is not hypothetical: ci_cortex_m.yml in ThreadX ran on master only while dev was the integration branch, so it gated no pull request anybody opened, and the ports drifted unnoticed for eight months.
• Third-party actions are pinned to a commit SHA, not a tag.
• Toolchain versions are pinned explicitly, so a bump is a reviewable commit.
• Dependabot is configured for the actions.

Definition of done

The workflows run green on a pull request, and the "Continuous integration" section of CONTRIBUTING.md is rewritten to replace the current placeholder — naming each check and when it runs.

[fdesbiens]

Scoped by the A3 Phase-0 plan, step 1 T7 and T8 (~/plans/A3-step1.md). T7 covers the FVP-execution workflow, modelled on threadx-fd's r52_fvp.yml; T8 covers the rest of the suite posture — compiler checks, pinned action SHAs, Dependabot, gcovr.

The rewrite of CONTRIBUTING.md's "Continuous integration" section that this issue's definition of done requires is step 8 T8.

[fdesbiens]

Status update — the workflows landed with the ZoneX repository foundation change. Leaving this open until they are observed green on a pull request; see "What is left" below.

What now exists

Four workflows, and every one of them triggers on pull_request against dev and main, and on push to dev and main. That was written from the requirement in this issue rather than discovered later: ci_cortex_m.yml in ThreadX ran on master only while dev was the integration branch, so it gated no pull request anybody opened and the ports drifted unnoticed for eight months.

Workflow	What it checks
host_tests.yml	The host unit tests, built with warnings as errors, plus a coverage report. Runs the terminology check as a separate job.
gcc_check.yml	Cross-builds every Cortex-R52 configuration — FVP, S32Z280, hard float — with the Arm GNU Toolchain 14.3.rel1, warnings as errors. Compiles and links; executes nothing.
clang_check.yml	The same sources with Arm Toolchain for Embedded 22.1.0. GNU as accepts non-canonical assembly forms that LLVM's assembler rejects, and ZoneX will be substantially assembly.
zx_fvp.yml	Builds the Cortex-R52 images and executes them on the Armv8-R AEM FVP, judging each by its self-reported result.

Both toolchains are fetched from their published releases, checksum-verified and cached, with no dependency on a third-party setup action, as this issue asked. Note for anyone touching gcc_check.yml: Arm's checksum file for arm-none-eabi is .sha256asc, not .sha256 — the latter contains an MD5 and sha256sum -c fails on it.

zx_fvp.yml exists now rather than later because there is no static check for "the partition still runs". Arm distributes the AEM FVP free of charge but behind a click-through licence with no stable unauthenticated URL, so the download location is the FVP_AEMV8R_URL repository variable (optionally FVP_AEMV8R_SHA256). When it is unset the build lanes still run and still gate the pull request; only execution is skipped, loudly, in the log and in the job summary. A silent green there would recreate the exact hole the workflow exists to close.

Supply chain

Every action is pinned to a 40-character commit SHA with the version in a trailing comment, and .github/dependabot.yml keeps those pins moving, targeted at dev. A SHA pin without Dependabot is worse than a floating tag — it freezes CI on whatever was current the day it was written, which is how actions/cache@v1 came to sit in a ThreadX workflow until GitHub began auto-failing every request that used it. Toolchain versions are pinned in the workflows so a bump is a reviewable commit. .github/CODEOWNERS routes every path to @eclipse-threadx/admins, which is also what routes Dependabot's reviewers.

One workflow addition beyond this issue's scope

scripts/check_terminology.sh, run as its own job in host_tests.yml. ZoneX targets Armv8-R AArch32, where both stages of address control are region-based MPUs; register names from the AArch64 system-register set, the translation-table registers and RISC-V memory-protection vocabulary are wrong here by construction, and code using one was written against the wrong architecture. That failure mode is cheap to fall into and reads plausibly, so it is checked mechanically rather than left to review.

What is left before this closes

Port checks, once ZoneX has more than one port. And the verification this issue actually asks for: the workflows have not yet run on a pull request, because ZoneX has had none. This stays open until a pull request shows them green.

One thing worth knowing for that first pull request: a pull_request trigger added after a branch was cut does not appear on an already-open pull request. Only a rebase makes new checks show up.

CONTRIBUTING.md's "Continuous integration" section now names each check and when it runs, replacing the placeholder.

[fdesbiens]

Fixed by #5. Closing.