fix(resolver): reject empty range rules

[Pybsama]

Why

The Rust resolver currently treats a range rule with neither a start nor an end
bound as matching every context value. That differs from the shared resolver
specification and the Java resolver, where an empty range is a normal
non-match.

The final boolean expression considered each absent bound automatically
satisfied, so an entirely empty rule evaluated to true.

What

• Return false when both range bounds are absent, while leaving all valid
  one-sided, inclusive, and exclusive comparisons unchanged.
• Remove the Rust-only expected-result override from the existing
  empty_range_rule resolver spec so Rust now uses the shared
  NO_SEGMENT_MATCH expectation.
• Rebuild the Go provider's committed embedded WASM resolver.

Validation

• TDD regression: removing the Rust override failed with
  expected RESOLVE_REASON_NO_SEGMENT_MATCH, got MATCH before the production
  change, then passed after the guard was added.
• Range-focused Rust tests: 21 passed.
• Core resolver release suite on the repository-pinned Rust 1.90.0 toolchain:
  371 passed.
• Core rustfmt and release Clippy on Rust 1.90.0.
• WASM guest rustfmt and release Clippy for wasm32-unknown-unknown on
  Rust 1.90.0.
• The rebuilt WASM asset byte-for-byte matches the pinned-toolchain build
  output (SHA-256
  2a51a26f8daba8d9ea5d66977ddec9a87b5b9ec049be6f9e13df16b02f7c945f).
• Go packages that consume and exercise the embedded resolver:
  confidence/internal/local_resolver and
  confidence/internal/flag_logger both passed.

The repository-wide Go target also contains real-backend E2E cases. In an
unconfigured local environment those existing cases stop at a missing
ClientSecret or mock-support-server 404, so they are not reported as passing
here.

Compatibility

No protobuf, dependency, or public API changes. Empty ranges now match the
shared cross-language contract; ranges with at least one bound keep their
existing behavior.

Closes #296.