Added a workflow that runs the Cortex-R52 images on the Armv8-R AEM FVP

[fdesbiens]

Nothing in CI executes a single instruction of any ThreadX port.

gcc_check compiles and links — its own header says it "executes nothing" — and its
CMake stage configures exactly one Cortex-R52 combination, the base FVP example with
-DTX_R52_ENABLE_MPU=ON. So a change that assembles cleanly, links cleanly and then
hangs on the first context switch passes every required check today.

This adds a workflow that builds both supported R52 configurations and runs them on the
Armv8-R AEM FVP, asserting each image's self-reported result. A missing result line is a
failure, never a pass, so a silent hang cannot masquerade as green.

The gap is wider than "nothing is executed"

gcc_check's CMake stage builds five images. The feature configuration builds eight:

Configuration	Images	New coverage
default	5	executed rather than only linked
feature — TX_R52_ENABLE_VFP + TX_R52_FLOAT_ABI=hard, TX_R52_ENABLE_FIQ, TX_R52_ENABLE_IRQ_NESTING, TX_R52_ENABLE_FIQ_NESTING	8	demo_m5, demo_fiq and demo_nesting are built nowhere in CI today

Those four options gate whole assembly blocks — the VMRS/VSTMDB/VLDMIA sequences, the
FIQ context paths, the nesting start/end pairs — that the default configuration never
assembles, let alone runs.

Where the model comes from

Arm distributes the Armv8-R AEM FVP free of charge but behind a click-through licence, and
there is no stable unauthenticated download URL to hard-code: the
developer.arm.com/-/cdn-downloads permalink forms all return 404 for this model.

So the location is a repository variable rather than a literal:

• FVP_AEMV8R_URL — a .tgz of the model. Required for the execution lanes.
• FVP_AEMV8R_SHA256 — optional. Set, the download is verified; unset, the run says so
  rather than pretending it verified anything.

When FVP_AEMV8R_URL is unset the build lanes still run and still gate the pull
request — only execution is skipped, and it says so with a ::warning:: and a job summary
entry. A silent green there would recreate the exact hole this workflow exists to close, and
contributor pull requests from forks keep working either way.

Details worth reviewing

The image list is read from the generated ninja graph, not kept in the workflow. The
images are EXCLUDE_FROM_ALL, so a bare build reports "no work to do" and would compare
nothing. Reading the graph means a target added to CMakeLists.txt cannot escape the check
because nobody remembered to list it here. Same technique, same reasoning, as
scripts/check_gcc.sh's CMake stage.

One job, not one per configuration, following the note in gcc_check.yml about folding
its two toolchains together: the checks list stays short and a cross-configuration
regression appears in one log rather than two.

The toolchain cache path and key match gcc_check.yml's AArch32 entry exactly, so the
two workflows share one cache entry instead of each holding its own copy of the same
archive. Change them together or the sharing silently stops.

find_program is overridden rather than patched. The example CMakeLists.txt locates
the model with HINTS $ENV{HOME}/FVP_Base_AEMv8R_11.32_19/bin, which is right on a
developer's machine and meaningless on a runner, so the resolved path is passed as
-DFVP_BASER_AEMV8R=<path>. No CMake file changes.

Validation

All three paths were exercised locally against the real model, GNU Arm 14.3.1:

Path	Result
model present	default 5/5, feature 8/8, step exit 0
FVP_AEMV8R_URL unset	both configurations built, execution skipped, exit 0, warning + summary emitted
a test fails (stub model)	::error:: per configuration, both still reported rather than stopping at the first, step exit 1

Not covered

The module manager port and the S32Z280 targets are not on dev yet — they are #639. Their
lanes belong in this workflow when they land, not in a second one; the matrix already has
the shape for them. The S32Z280 targets will be build-only in CI regardless, since a hosted
runner has no silicon.