COMP: Decide the x86-64 microarchitecture baseline for distributed ITK packages (sibling of #6745)

**Sibling of #6745.** Both concern the ISA-level policy in `CMake/ITKSetStandardCompilerFlags.cmake`'s `check_compiler_optimization_flags()` — #6745 asks how high the *ceiling* should go (`-march=x86-64-v4` and whether `-mprefer-vector-width=256` must accompany it); this asks where the *floor* should sit for redistributed packages. RHEL 9, Fedora, and SUSE all require `x86-64-v2` of their packages; ITK currently emits no `-march` at all.

The question is sharper than "should we raise the floor," because `7c0bfe8654e` (2026-04-13) removed `-march=corei7` — which was roughly v2-equivalent — without replacing it. **ITK's effective distribution baseline may have moved down, not held steady.**

What the tree does today

`check_compiler_optimization_flags()` sets no architecture flags and says why:

```cmake
# No architecture-specific optimization flags are set by default,
# ensuring maximum redistributability for pip wheels, Docker images,
# and hardware translation layers (Rosetta, QEMU).
# Users building for local performance should add -march=native via
# CMAKE_C_FLAGS/CMAKE_CXX_FLAGS or CMakeUserPresets.json.
```

This is a deliberate, documented position, not an oversight. The purpose of
this issue is to decide whether it is still the right one for *distributed
binaries*, or whether build-from-source and wheel/package builds should be
allowed to diverge.

What changed, and why "floor" is the right word

`7c0bfe8654e` — *"COMP: Remove hardcoded -march=corei7, -mtune=generic, and dead code"* (2026-04-13) removed:

```cmake
-mtune=generic # for reproducible results (#1939)
-march=corei7 # ABI settings to support corei7 (circa 2008 ABI feature sets)
```

`corei7` (Nehalem, 2008) implies SSE4.2 / POPCNT / CMPXCHG16B — essentially
the `x86-64-v2` feature set under a non-standard spelling. So ITK shipped
with ~v2 assumptions for years and now ships with none.

Whether that matters depends entirely on whether any redistributed artifact
was actually built through this code path. That is the first thing to
establish, and it is answerable rather than arguable.

Prior art — the abstraction was proposed and withdrawn

PR #6039 (*"COMP: Replace hardcoded -march=corei7 with ITK_X86_64_ISA_LEVEL"*)
proposed a cache variable with options `default / x86-64 / x86-64-v2 /
x86-64-v3 / x86-64-v4 / native`. It was closed 2026-04-13 in favour of simply
deleting the hardcoded flag, with the note that *"the ISA level abstraction
can be revisited later if needed."* This issue is that revisit.

The reasoning recorded at the time for defaulting to plain baseline rather
than v2:

- pip wheels, Docker images, and translation layers (Rosetta 2, QEMU) only
guarantee baseline `x86-64`
- Fedora/RHEL 9 and SUSE use `x86-64-v2` as a *distro* minimum
- users building locally for their own hardware should use `-march=native`

Proposed work

1. **Establish the factual baseline first.** Determine which redistributed
artifacts (PyPI wheels, conda packages, Docker images) actually pass
through `check_compiler_optimization_flags()`, and what `-march` each
effectively compiles with today. Without this the rest is speculation.
2. **Decide whether build-from-source and package builds should diverge.**
A distro-style `x86-64-v2` floor for packages is compatible with keeping
source builds at plain baseline; they need not share a default.
3. **If a floor is adopted**, decide the mechanism — reviving #6039's
`ITK_X86_64_ISA_LEVEL` cache variable, or a narrower packaging-only
setting — and document the guaranteed minimum explicitly, which ITK does
not currently state anywhere.
4. **Quantify before adopting.** Any floor should be justified by measured
benefit on ITK's own workloads, not by matching distro policy for its own
sake. #6745's Resample sweep is the template, and its finding that
`-march=x86-64-v4` *regresses* BSpline by 12–17% is a direct warning that
higher is not automatically better.

Counter-arguments that must survive

- **Rosetta 2 / QEMU.** Translation layers are the strongest argument for
staying at baseline; a v2 floor could break x86-64 wheels under emulation.
- **Nothing is obviously broken.** No user report motivates this. The case is
consistency-with-distros plus recovering the pre-`7c0bfe8654e` position,
which is weaker than a defect report.
- **The gain may be negligible.** SSE4.2/POPCNT are unlikely to move ITK's
memory-bound kernels much. See item 4 — this may resolve as "document the
current baseline and close."

An entirely legitimate outcome is: *confirm plain baseline is correct, state
it explicitly in the documentation, and close.* The current situation —
no stated guarantee either way — is the part worth fixing regardless.

Start in CMake/ITKSetStandardCompilerFlags.cmake at check_compiler_optimization_flags(), then trace the PyPI, conda, and Docker build paths to determine whether they use it and which ISA flags are effective. Review commit 7c0bfe8654e and PR #6039, and use #6745's Resample measurements as the performance reference. Done means the artifact baseline is established, the source/package policy is decided, and the guaranteed minimum is implemented or explicitly documented.

Written by the indexing model from the issue text.