ENH: Umbrella — stage VNL → Eigen numerics migration

# ENH: Umbrella — stage VNL → Eigen numerics migration

Spun out of the Q5 decision on #6230. Maintainer sentiment there favored reviving the long-dormant 2018 plan to migrate ITK's internal numerics from VNL to Eigen; this issue stages that work as an incremental, multi-release deprecation rather than a single break.

Why now / background

The VNL → Eigen aspiration dates to the 2018 internal-Eigen adoption ([Discourse #1429](https://discourse.itk.org/t/add-internal-third-party-module-eigen3/1429)) and was reaffirmed on #6230 (Q5) by @thewtex ("+1 for replacing VNL"), @hjmjohnson, and conditionally @dzenanz ("a whole lot of work; if someone is willing to do it"). @phcerdan noted the main hard dependency is VNL's FFT layer, with candidate replacements [pocketfft](https://github.com/mreineck/pocketfft) / [ducc](https://github.com/mreineck/ducc).

Recent groundwork already reduced VNL surface: `vnl_random` → `std::` random variants.

Proposed staging (incremental, value-tolerant)

1. **`vnl_svd` → Eigen SVD** (first step; @hjmjohnson). Expect numerical drift from algorithmic differences — fortify affected tests with tolerance-based comparison rather than bit-identical baselines.
2. Inventory remaining `vnl_*` linear-algebra call sites (matrix/vector, eigenvalue, least-squares).
3. FFT layer — evaluate pocketfft/ducc as `vnl_fft` replacement (most permissive licensing vs FFTW).
4. Deprecation cycle for public accessors (`GetVnlVector` → `GetInternalVector`, per @phcerdan 2018) spanning ≥2 releases.

Each step is a separate PR; this issue tracks the set.

Blocked-by / depends-on: the #6230 architectural commitment that Eigen stays TU-local and out of public ITK API holds for any new Eigen usage introduced here.