ci: record why LTO is a flag and not CMAKE_INTERPROCEDURAL_OPTIMIZATION

The CMake variable is the tidier spelling and would cover the MSVC job too, so
it is the obvious thing to reach for and worth saying why it was not.

It builds and links, CUDA included - and it does not reach .cu targets either
way, so there is no -dlto risk on either route. But it optimises less: 396.9 G
retired instructions against 384.9 G for -flto=auto, three runs each, with a
0.45% run-to-run spread, so a 3% gap is not measurement luck. Of 107 static
libraries the two routes agree within 5% on 105; the flag additionally covers
FFTW and libzmq. And CMAKE_AR stayed plain ar under the variable, so the
archive-handling argument for it did not hold here either.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.gitea/workflows/build_and_test.yml

@@ -11,6 +11,13 @@ env:
   # than CPU-instruction-bound. It costs about 3x on an INCREMENTAL rebuild (one file plus link,
   # 9.8 s -> 30.1 s), which is why it belongs here and not in CMakeLists: CI always builds from
   # scratch and ships the result, so it pays the link once and a developer never pays it at all.
+  #
+  # Not CMAKE_INTERPROCEDURAL_OPTIMIZATION, which is the tidier spelling and would cover MSVC too:
+  # built and linked fine (CUDA included, and it does not reach .cu either way), but measured 3%
+  # MORE retired instructions than -flto=auto - 396.9 G vs 384.9 G over three runs each against a
+  # 0.45% run-to-run spread, so the gap is real. It also leaves two dependencies (FFTW, libzmq) out
+  # of LTO that the flag reaches, and it did not switch CMAKE_AR to gcc-ar here, so the one
+  # correctness argument for it did not materialise either.
   LINUX_CMAKE_FLAGS: '-DCMAKE_CXX_FLAGS="-march=x86-64-v3 -flto=auto" -DCMAKE_C_FLAGS="-march=x86-64-v3 -flto=auto"'
   # MSVC has no spelling for the x86-64-v2 level; /arch:AVX is the nearest and implies SSE4.1/4.2,
   # which is what matters here - without it Eigen has no vectorised round and falls back to a libm