ENH: Define and audit a production-readiness rubric for ITK remote modules

ITK's ~60 remote modules vary widely in test coverage, CI freshness, wheel
health, and maintainer activity, and there is no published definition of what
"production ready" means for one. This proposes a rubric plus a periodic audit.

Why now — the evidence

Every open remote-module issue on the tracker is a narrow, individually-filed
defect rather than a symptom anyone is aggregating:

| Issue | Last updated | Subject |
|---|---|---|
| #4761 | — | `cmake_minimum_required` across remote modules |
| #3795 | 2022-12-22 | Remote modules fail to checkout git tag, succeed with commit hash |
| #3754 | 2023-06-06 | Many remote modules enabled → configure fails: No such module "ITKIOPNG" |
| #2238 | — | `Python3_ROOT_DIR` handling |
| #1627 | — | Remote module build failures |
| #1024 | — | `ApplyScriptToRemotes.sh` |
| #990 | — | Doxygen of `Remote/` directories |

Two of those (#3795, #3754) have been open with no activity for 3+ years, which
is itself a signal that no one owns remote-module health as a category.

The ingestion tracker #6160 is closed and was scoped to ingest/archive
decisions, not to grading module maturity. Nothing currently states criteria for
"production status" or audits modules against them.

Proposed rubric (starting point for discussion)

A module is **production ready** when all of:

1. CI green on the current `ITKRemoteModuleBuildTestPackageAction` (not a stale
pinned action, and not CircleCI-only).
2. Non-trivial test coverage — at least one test per public filter, exercising
real data rather than construction-only smoke tests.
3. Python wheels published for the currently-supported Python versions.
4. A README documenting purpose, a citation if research-derived, and at least
one usage example.
5. An identifiable active maintainer (a commit or issue response within 12
months).

Deliverables:

- Publish the rubric (suggest `Documentation/remote_modules_classification.yaml`
gains a `readiness:` field, since that file already exists and already needs a
correctness pass).
- Run the audit once, publish the resulting table.
- Use the rubric as the gate for promotion/ingestion into ITK proper vs.
archival.

Deep-dive notes already exist locally for ITKVariationalRegistration, ITKMontage,
ITKVkFFTBackend, ITKIOOpenSlide, and ITKIOTransformDCMTK and can seed the first
five rows.

Start by reading Documentation/remote_modules_classification.yaml and the ITKRemoteModuleBuildTestPackageAction referenced in the rubric. Review the existing deep-dive notes for ITKVariationalRegistration, ITKMontage, ITKVkFFTBackend, ITKIOOpenSlide, and ITKIOTransformDCMTK. Done means the rubric is published, the remote modules are audited in a resulting table, and promotion or archival decisions can use the criteria.

Written by the indexing model from the issue text.