feat(sdk): gate supernode candidates by minimum version (>= 2.5.0)

[mateeullahmalik]

Summary

Adds an SDK-side compatibility gate that refuses to upload to supernodes running a version older than pkg/version.MinSupernodeVersion (currently 2.5.0).

Closes the only real activation-hazard surfaced in the v1.11.1 → v1.12.0 upgrade-survival review: an SDK client that has adopted the post-upgrade contract (e.g. LEP-5 AvailabilityCommitment at register, requiring ChunkProof[] at finalize) being paired with a pre-LEP-5 supernode during the asynchronous mainnet rollout window.

Why

Side	Upgrade timing
Chain	Atomic at the halt height — no staging possible
Supernode fleet	Asynchronous over hours-to-days — operators control their own boxes; we cannot force a schedule

Without a gate, a v1.12.0 client paired with a v2.4.x supernode submits an action that no SN can finalize. The action sits in PROCESSING until expiry → per-action data loss, no chain-wide impact, but visibly broken uploads during the rollout window.

The SDK is the only layer that can read both sides (chain params + candidate SN's reported version) and refuse the pairing. This PR is that gate.

What

File	Change
pkg/version/min_supernode.go	New const MinSupernodeVersion = "2.5.0" — single source of truth
pkg/version/compatibility.go	New IsCompatibleSupernodeVersion(reported string) bool using Masterminds/semver/v3. Floor is compared as 2.5.0-0 so all 2.5.0-rc* / -beta / +meta pre-releases are eligible. Fail-closed on empty / unparseable input.
pkg/version/compatibility_test.go	25 table-driven cases covering all four invariants below
sdk/task/task.go	filterEligibleSupernodesParallel consults StatusResponse.version from the existing per-candidate GetSupernodeStatus probe (no new RPC). Rejected nodes get a clear reason: supernode version X is below SDK minimum 2.5.0.

Invariants

#	Invariant	Enforcement point	Test
I1	No SN with version < 2.5.0 reaches the upload step	filterEligibleSupernodesParallel (sole filter entry)	8 rows (floor, above-floor, way-above; pre-floor patch/minor/major)
I2	Empty / unparseable / missing version → ineligible (fail-closed)	Same point	6 rows (empty, whitespace, garbage, partial, letters, negative)
I3	Single source of truth for the version floor	pkg/version/min_supernode.go const	Grep verifies no inline "2.5.0" literal outside pkg/version
I4	2.5.0-rc*, -beta, +build of the floor base are eligible	Semver comparison vs 2.5.0-0	7 rows incl. 2.5.0-rc1, v2.5.0-rc2, 2.5.0-rc2+build.5, -beta, -alpha.1, -0 boundary, and negative 2.4.99-rc1

Test output

=== RUN   TestIsCompatibleSupernodeVersion
--- PASS: TestIsCompatibleSupernodeVersion (0.00s)
    --- PASS: floor_exact_2.5.0
    --- PASS: floor_with_v_prefix
    --- PASS: patch_above_floor
    --- PASS: rc1_of_floor              <-- 2.5.0-rc1 is eligible
    --- PASS: rc2_of_floor_with_v       <-- v2.5.0-rc2 is eligible
    --- PASS: rc_with_build_meta        <-- 2.5.0-rc2+build.5 is eligible
    --- PASS: rc_of_pre-floor_version   <-- 2.4.99-rc1 is rejected
    --- PASS: one_patch_below_floor     <-- 2.4.72 is rejected
    --- PASS: empty_string              <-- fail-closed
    --- PASS: garbage                   <-- fail-closed
    ... (25 cases total)
=== RUN   TestMinSupernodeVersion_IsValidSemver
--- PASS: TestMinSupernodeVersion_IsValidSemver
ok      github.com/LumeraProtocol/supernode/v2/pkg/version
ok      github.com/LumeraProtocol/supernode/v2/sdk/task

Rollout semantics

• 2.5.0-rc1 is eligible — this is intentional and confirmed with @mateeullahmalik. The forthcoming SN release will tag as v2.5.0-rc1 first; the gate must let it through.
• 2.4.72 and earlier are rejected — that is the entire point.
• v2.5.0 is eligible — leading v is tolerated.

What is NOT in this PR

• Chain-side enforcement — out of scope. SDK is the available lever.
• sdk-go / sdk-js / sdk-rs direct changes — sdk-go picks this up automatically on the next supernode dep bump (it imports pkg/version transitively via sdk/task). sdk-js and sdk-rs need their own gates (follow-up issues to file).
• Full live-devnet E2E — deferred until a real v2.5.0-rc1 supernode binary is cut. Today there is no SN tag at or above the floor, so a live test would just confirm that the gate rejects everything (which the unit tests already prove deterministically). A live E2E should be run as part of the v2.5.0-rc1 release validation against a mixed-version fleet (one stale v2.4.72 + one v2.5.0-rc1). I'll run it then via the cascade-register-rs-snapi skill.

Risks & mitigations

Risk	Mitigation
Status RPC returns empty version (regression in a future SN build)	Fail-closed: such an SN is rejected. Visible in logs with a clear reason.
Some future SN release reports version via a different field	Caught immediately — every cascade will fail with version <unreported> is below SDK minimum 2.5.0. No silent passthrough.
Const drift over time (someone hard-codes "2.5.0" elsewhere)	I3 invariant — grep before merge of any future PR. CI lint could enforce.
Floor accidentally set to an unparseable string	TestMinSupernodeVersion_IsValidSemver guards this — package will not compile cleanly.

Rollback

Revert is safe and clean: the change is additive within an already-failing branch of filterEligibleSupernodesParallel. Reverting removes the version check; the existing peers / health / balance gates remain.