Compiled the module manager C sources, which no check had ever built

[fdesbiens]

Follow-up to #672.

Problem

#672 corrected this script's assembly glob and brought the module ports into the count — but only their assembly. Their C stayed outside every check:

• 27 files of portable module manager under common_modules/module_manager/src
• the per-port code under ports_module/<core>/gnu/module_manager/src

By this script's own standard, stated three times in its comments — a port that is simply absent from the count reads as covered — 293 files across nine Arm module ports were compiled by nothing, with either compiler.

Change

A sixth stage compiles the portable module manager plus each port's own C, once per Arm module port. Every module port ships its own tx_port.h and txm_module_port.h carrying the control-block extensions the dispatch code needs, so a port is compiled against its own headers rather than the base port's.

Two details the ports themselves dictate, both found by running the stage rather than by reading:

SMP ports take common_smp/inc. Pairing cortex_a35_smp with the single-core headers hid _tx_thread_smp_protect and _tx_thread_smp_unprotect behind implicit declarations and lost tx_thread_smp_core_executing from TX_THREAD — fourteen files reporting errors for a port that builds correctly. That was the harness being wrong, not the port.

TrustZone ports need -mcmse, or cmse_nonsecure_entry is silently ignored rather than honoured. tx_thread_secure_stack.c additionally carries GCC's optimize attribute, which clang does not implement. That one is a genuine toolchain divergence in a file GCC builds cleanly, so it is suppressed by name rather than left to fail.

Result

== Module manager C sources, one per Arm module port ==
  cortex_a35: 30 of 30 compiled
  cortex_a35_smp: 30 of 30 compiled
  cortex_a7: 33 of 33 compiled
  cortex_m0+: 32 of 32 compiled
  cortex_m23: 36 of 36 compiled
  cortex_m3: 32 of 32 compiled
  cortex_m33: 36 of 36 compiled
  cortex_m4: 32 of 32 compiled
  cortex_m7: 32 of 32 compiled

Full run green, all stages, including the example builds.

The stage was verified to actually fail

A check that only ever passes proves nothing, so defects were injected into a throwaway worktree: one in common_modules, one in a single port's own source. The shared defect is reported under every port; the port-specific one only under that port; counts decrement correspondingly.

Interaction with #639

The stage globs ports_module/*/gnu/module_manager/src, so a new module port is picked up automatically with no edit here — which is the point, but it means #639 (Cortex-R52 module manager port) is affected.

Running this stage against #639's head, nine ports pass and R52 reports:

ports_module/cortex_r52/gnu/module_manager/src/txm_module_manager_offset_check.c:58:
  fatal error: 'mpu.h' file not found

mpu.h exists only under ports/cortex_r52/gnu/example_build/{fvp_baser_aemv8r,s32z280_evb}/. With either on the include path the file compiles cleanly, so it is not broken — it is a port source depending on a board-specific header from an example build directory, and it cannot be compiled as a port source on its own. Worth noting that the two board copies of mpu.h differ, and this file exists to statically assert offsets the port's assembly hard-codes, so which board is reachable is not obviously immaterial.

That is for #639 to resolve; flagging it here because merging this first will surface it there.