Refreshed the reason gcc_check leaves RISC-V out (#722)

The header explained the exclusion by saying RISC-V "is not regressing" and
that adding it would widen the toolchain download. The second half is still
true; the first read as though nothing in CI exercised the family at all,
which stopped being the case with #717.

RISC-V is now the best-covered of the four excluded families rather than the
least: regression_test.yml builds both ports and runs 955 tests on them under
QEMU -- 475 on RV32 and 480 on RV64, across five build configurations each --
which is more than a compile-and-link check could establish. That is a
stronger argument for leaving it out of this workflow than the original, so
the sentence now makes it.

The download figure is kept and quantified: the two bare-metal toolchains this
workflow would have to fetch are about 500 MB apiece.

Comment only; no behaviour change. scripts/check_gcc.sh names the same four
families but states the exclusion without giving a reason for it, so it needs
no matching edit.

Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>

.github/workflows/gcc_check.yml

@@ -21,8 +21,11 @@ name: gcc_check
 #
 # What it does not cover: it compiles and links and **executes nothing**. The
 # Cortex-R52 FVP ctest suite is not part of it. RISC-V, MIPS, RX and ARC are
-# outside it entirely -- RISC-V deliberately, as both its ports do assemble and
-# adding them widens the toolchain download for a family that is not regressing.
+# outside it entirely -- RISC-V deliberately, and now for a stronger reason
+# than when this was written: regression_test.yml builds both its ports and
+# runs 955 tests on them under QEMU, which is more than a compile check could
+# say. Adding them here would widen this workflow's toolchain download by about
+# a gigabyte to re-prove a subset of that.
 #
 # It does not supersede cortex_m. That workflow builds four ports *through
 # CMake*, which is the only thing exercising cmake/cortex_m*.cmake and the