Stated the compiler and coverage requirements directly, and said who the pinned toolchain default serves

[fdesbiens]

Two comment-only changes, both about comments that told a reader something
they could not act on. No behaviour changes anywhere in this PR.

1. Requirements cited a document nobody can open

Seven comments across five files cited a maintainer-local document as the
source for two project requirements: that GCC 14 on Linux is the default
compiler, and that the coverage target is 100%. That document is not part of
this repository and is not published anywhere, so the citation gave a reader
nothing to follow -- it named a source they cannot open, in place of simply
stating the requirement.

Both requirements are real and both stay. Only the pointer goes: each comment
now states the requirement on its own terms, which is what the surrounding
prose was already doing everywhere else.

File	Comment
cmake/cortex_r52.cmake	the pinned reference toolchain
scripts/check_gcc.sh	why the script exists
.github/workflows/gcc_check.yml	why the workflow exists, and the GCC_VERSION pin
.github/workflows/r52_fvp.yml	the GCC_VERSION pin
.github/workflows/regression_template.yml	the coverage floor, twice

2. The pinned toolchain default did not say who it serves

cmake/cortex_r52.cmake and cmake/cortex_m52.cmake both default
ARM_TOOLCHAIN_PATH to a toolchains directory under the user's home, guarded
by an EXISTS check. Nothing said whether CI relies on that, and the natural
reading is that it does.

It does not. The three workflows that install a toolchain unpack it into the
workspace and cache it there, and r52_fvp.yml puts that directory on PATH
before configuring; scripts/check_gcc.sh passes -DARM_TOOLCHAIN_PATH at
each of its three CMake call sites. On a runner the guarded directory is
absent, the EXISTS check falls through, and the compiler comes from PATH.
The default only ever fires on a developer machine, where it is what makes a
no-flag build work.

Both comments now say that, so the default is not mistaken for a CI dependency
and not removed as dead code. cortex_r52.cmake carries the explanation and
cortex_m52.cmake refers to it, matching the cross-reference already there.

The r52 comment also claimed absolute paths mean "the build does not depend on
PATH ordering", which is only true where the pinned directory exists -- in CI
the build depends on PATH and nothing else. Qualified accordingly.

Verification

Comments only. Two paragraphs are rewrapped where the shorter text left a
ragged line.

• scripts/check_gcc.sh --help still prints the intended block. The script
  slices its own header by line number to produce that output, so an edit
  above it is worth checking rather than assuming.
• cmake/cortex_r52.cmake and cmake/cortex_m52.cmake both still configure.
• The fall-through described above is real, not assumed: with HOME pointed
  at a directory holding no toolchains, cortex_r52.cmake configures against
  the arm-none-eabi-gcc found on PATH.
• All three workflow files still parse as YAML.