feat!: fractional bucketing improvements

[toddbaert]

High-precision and nested fractional

This is a coordinated feature across flagd and all flagd providers.

• fractional now supports up to max-int32 total weight and 1/max-int32 resolution as described in the high-precision fractional bucketing ADR
• fractional now supports computed (nested JSONLogic) variants and weights as described in the fractional ADR
• Includes e2e tests from the flagd-testbed v3.1.0...v3.4.0 to validate consistent fractional bucketing across all provider implementations
• ⚠️ Pseudorandom hash assignments will change with this release due to changes in the hashing algorithm; update flagd and your providers to ensure fractional assignment is consistent across all workloads

Related PRs

Component	PR
flagd	open-feature/flagd#1909
java-sdk-contrib	open-feature/java-sdk-contrib#1740
js-sdk-contrib	open-feature/js-sdk-contrib#1501
python-sdk-contrib	open-feature/python-sdk-contrib#373
dotnet-sdk-contrib	#622
flagd-schemas	open-feature/flagd-schemas#207

Warning
@toddbaert will coordinate the release across flagd and all providers. Do not merge without coordination.
@toddbaert will update the RPC mode tests accordingly once the associated flagd PR is merged and an up-to-date flagd-testbed image is available.

---

Original PR description

• allows bucketing weights summing up to MaxInt32 (=2,147,483,647)
• allows nesting of and within the fractional operator
• allows all primitives as bucket variants

Fixes: #607
Fixes: #608

[gemini-code-assist]

Code Review

This pull request implements the v2 fractional bucketing algorithm, which supports multiple variant types and uses 64-bit arithmetic for improved precision. The changes include updated E2E test hooks and new unit tests. A potential overflow bug was identified in the weight resolution logic where casting a double to an integer before clamping could lead to incorrect values for inputs outside the 32-bit range.

[askpt]

LGTM! Just a minor request.

I noticed you added this is a "breaking change". Could you please explain the motivation to make it so? It might be worth to add that information to the Changelog file.

[toddbaert]

It's only this. It's just a behavioral change in "random" assignments, not API surface change. I debated not making it breaking at all, but in some cases users will want to keep things consistent WRT random assignment across workloads, so they will have to update flagd deps to do that.

• ⚠️ Pseudorandom hash assignments will change with this release due to changes in the hashing algorithm; update flagd and your providers to ensure fractional assignment is consistent across all workloads