fix: exact version match in accept header validation

[mmagician]

Summary

The AcceptHeaderLayer::new constructs a semver Comparator with patch: None and pre: Prerelease::default() (empty), effectively creating a version requirement like =0.14. While the patch: None correctly allows any patch version through (so 0.14.0 and 0.14.1 are both accepted), the empty pre-release causes semver's VersionReq::matches to reject all pre-release versions. Per semver matching rules, a comparator without a pre-release component never matches versions that have one.

This means during the alpha release cycle, no client can pass version negotiation - a client at 0.14.0-alpha.3 is rejected even by its own node at 0.14.0-alpha.3.

Fix

The VersionReq alone can't express "match major.minor with any patch, but require exact pre-release" because of how semver treats pre-release comparisons. Instead, we:

1. Keep the VersionReq as-is for major.minor matching (with patch: None, pre: empty)
2. Store the expected pre-release tag separately in expected_pre
3. In negotiate, strip the pre-release from the client version before checking VersionReq, then check the pre-release tag separately for an exact match

This gives us the desired compatibility rules:

• Patch versions are compatible: 0.14.0 and 0.14.1 are both accepted by a 0.14.0 node
• Pre-release tags must match exactly: alpha.3 only matches alpha.3, not alpha.1 or beta.3
• Stable and pre-release are not compatible: a 0.14.0 client is rejected by a 0.14.0-alpha.3 node and vice versa

Test changes

• Added version_prerelease_rejected_by_stable case (a stable server rejects pre-release clients)
• Added a prerelease test module that creates a server at 0.14.0-alpha.3 and verifies:
  • Exact pre-release match passes
  • Different patch with same pre-release tag passes (0.14.1-alpha.3)
  • Different pre-release number (alpha.1) is rejected
  • Different pre-release tag (beta.3) is rejected
  • Stable version (0.14.0) is rejected

Context

Discovered while running integration tests for the miden-client release/v0.14.0-alpha branch. The client (at 0.14.0-alpha.1) was rejected by the test node (built from miden-node-rpc at 0.14.0-alpha.3) with:

accept header validation failed: server rejected request
(client version: 0.14.0-alpha.1, genesis commitment: none)

See: https://github.com/0xMiden/miden-client/actions/runs/22726117886/job/65902524781?pr=1862

[igamigo]

LGTM! I guess another potential fix could've been to strip the alpha suffix from the client's side, but this sounds like it's more correct even if it incurs another release

[sergerad]

Makes sense I'm just not certain we want this behaviour:

Pre-release tags must match exactly: alpha.3 only matches alpha.3, not alpha.1 or beta.3

Might be more helpful to require exact match on alpha/beta and ignore the number?

[bobbinth]

Might be more helpful to require exact match on alpha/beta and ignore the number?

I think this may be preferable as well. Basically, we'd have 0.14.0-alpha.3 node accept 0.14.0-alpha.x client (0.14.0-alpha.1, 0.14.0-alpha.2 etc.). This would allow us to evolve client and node codebases somewhat independently (e.g., a bugfix in the node does not need to trigger re-deployment of the client and vice-versa). And if we did want to make them incompatible - we could use beta, gamma etc.

[Mirko-von-Leipzig]

I think this indicates that its time to version the gRPC schema separately since its largely more stable than the number of versions we'll be releasing elsewhere.

The main thing preventing this is the protocol types which we raw encode. Since we effectively inherit its stability as well. But we could also pin the version used in the grpc crate(s) to get some stability guarantees.

---

Given that ^^ should be our target (~soonish), I think we can just do something lenient for the alpha stuff so that it gets out of they way. Basically what @bobbinth and @sergerad suggest -- match on the alpha but ignore the number suffix.

[mmagician]

I think this may be preferable as well. Basically, we'd have 0.14.0-alpha.3 node accept 0.14.0-alpha.x client (0.14.0-alpha.1, 0.14.0-alpha.2 etc.). This would allow us to evolve client and node codebases somewhat independently

We discussed both options in the sync meeting and the current approach (of exact match on both alpha AND x) was what we all agreed on to implement to unblock us with alpha - unless I misunderstood / missed something?

In any case, the other approach is relatively simple as well, I opened another PR targeting the same branch to compare: #1755

[igamigo]

We can close this after #1755 got merged, right?