clnvm: Make CLN version selection deterministic and bounded

[cdecker]

Problem

The test harness picked the default CLN node version with a lexicographic max() over the manifest tags (and a [... "gl" ...][-1] in the paths fixture). As soon as a new release lands in the shared manifest.json it becomes the default for the entire suite — even if the client and signer don't support it yet.

That is how v26.06gl1 started being used as the default node in CI (e.g. run 28375003252), before support was built into the client/signer — causing failures like Unknown command 'decodepay'.

Change

Make version selection deterministic and explicitly bounded:

• Add version_sort_key() / version_base() that parse vX.Y[.Z][glN] tags into numeric, ordered keys. The glN suffix is a separate component, so ordering is numeric (not lexicographic, fixing the latent gl10 < gl2 bug) and the base version can be compared independently of the greenlight suffix.
• Add ClnVersionManager.supported_versions(lowest, highest) and latest_supported(lowest, highest), filtering to base versions within [lowest, highest] inclusive and dropping non-numbered tags (main).
• Make the existing latest() deterministic too.
• In the gl-testing fixtures, pin LOWEST_SUPPORTED_VERSION explicitly and derive HIGHEST_SUPPORTED_VERSION from glclient.__version__ — i.e. whatever the signer (libhsmd) actually supports. The suffix is ignored when comparing, so the signer reporting v25.12 matches v25.12gl1 but excludes v26.06gl1.

When the signer is bumped to support a new release, that single glclient.__version__ constant moves and the suite picks it up automatically.

Tests

Adds offline unit tests in test_version_manager.py covering the sort key, suffix-ignoring base comparison, filtering, and the "default is v25.12gl1, never v26.06gl1" guarantee. Verified end-to-end against the live manifest: selection yields v25.12gl1 and excludes v26.06gl1 and main.

🤖 Generated with Claude Code