COMP: Update CI, Python packaging, and CMake 4.x compatibility

[hjmjohnson]

Consolidate all pending CI and packaging updates that restore ITKCleaver's buildability on current toolchains (CMake ≥ 4.0). Supersedes #63, #70, #72, #73, #74, #75.

The one red check — build-test-wasm — is pre-existing (it is also red on master at 3d0fd19) and is not caused by this PR; see details below.

What's in this PR (4 commits)

1. Update CI workflows to latest action versions + ITK v5.4.6
2. Update itk-wasm build images to 20250619-3165ade4
3. Bump version to 1.4.1 and require Python ≥ 3.10
4. Disable vendored Cleaver-lib testing for CMake 4.x compat (vendored googletest declares cmake_minimum_required(VERSION <3.5), which CMake 4 hard-rejects; the ITK module keeps its own tests). Matches upstream fix COMP: Modernize CMake for add_subdirectory, googletest, and CMake 4.0 compatibility Cleaver#130.

Status of the pre-existing wasm CI failure (updated)

The wasm job is red on master as well, so this is not a regression. With this PR's CI updates (newer itk-wasm build image), the failure mode has shifted downstream:

• The C++ Build and Test WASI steps now pass (the earlier itkOverrideGetNameOfClassMacro-style C++ break from the older Docker image no longer occurs).
• The failure is now in the Build TypeScript, JavaScript package step — tsc errors from an itk-wasm version skew between the bindgen output and the itk-wasm npm dependency:
  • index-common.ts: TS2307: Cannot find module './version.js'
  • two TS7016 — worker .min.worker.js bundles lack .d.ts
  • itk-cleaver.ts:76: TS2554: Expected 4-5 arguments, but got 6

This PR does not touch any wasm/typescript/src/*.ts; resolving it requires aligning the bindgen image with the npm itk-wasm version (or committing regenerated bindings) — out of scope for this CMake-4 / packaging maintenance batch. Happy to split the CMake-4 hunk into a minimal standalone PR if that's easier to merge.

[netlify]

✅ Deploy Preview for itk-wasm-cleaver-typescript-docs ready!

Name	Link
🔨 Latest commit	e6a55a1
🔍 Latest deploy log	https://app.netlify.com/projects/itk-wasm-cleaver-typescript-docs/deploys/69dffbbce43a6e000842aa55
😎 Deploy Preview	https://deploy-preview-77--itk-wasm-cleaver-typescript-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[hjmjohnson]

Abandoning update to Cleaver. If this project becomes active again, revisit closed PRs.

[hjmjohnson]

@thewtex @jcfr — could I ask you to take a look at merging this? It's a small, COMP-only change that restores ITKCleaver's buildability on current toolchains, and right now it's the one thing keeping the module red.

Why it matters: ITKCleaver no longer configures with CMake ≥ 4.0 (now the default toolchain; ITK itself builds under it). The vendored Cleaver library pulls googletest via ExternalProject, and that googletest declares cmake_minimum_required(VERSION <3.5), which CMake 4 hard-rejects ("Compatibility with CMake < 3.5 has been removed"). The Cleaver library and the ITK module compile cleanly — only the vendored lib's internal googletest test build trips the policy floor.

This PR fixes it by turning the vendored Cleaver-lib's internal BUILD_TESTING off (the ITK module keeps its own tests), matching the upstream Cleaver fix SCIInstitute/Cleaver#130.

How this surfaced + scope

Found while building the full ITK consumer "forest" (every downstream — ITK, ANTs, BRAINSTools, Slicer, elastix, SimpleITK, and all remote modules — against ITK main to catch breakage before it lands). With the pinned CMake 4.3 toolchain, ITKCleaver is the only remote-module red attributable solely to this googletest policy floor; the change here makes it green again.

The change is limited to the SuperBuild's handling of the vendored library's tests — no functional change to the module. (The rest of this PR — CI action bumps, Python packaging, .cid data tags — is the consolidated maintenance batch from #63/#70/#72–75; happy to split the CMake-4 hunk into a minimal PR if you'd prefer to merge that alone.)

One bigger-picture ask: this module has been dormant on my end, and the natural home for an ITK remote module is alongside the others. Would you be open to transferring ITKCleaver to the InsightSoftwareConsortium organization? That would put it next to the rest of the remote modules and let the ITK maintainers keep it current (CMake/ITK API churn, dashboards) rather than it going stale under SCIInstitute. I'm glad to help with the move and to hand off / co-maintain.

Thanks!

[thewtex]

Would you be open to transferring ITKCleaver to the InsightSoftwareConsortium organization?

This is a questions for the SCI folks.