Rust resolver returns InternalError for circular segment dependencies

[nicklasl]

Problem

When a circular segment dependency is detected, the Rust resolver returns an InternalError. Java returns NO_SEGMENT_MATCH, consistent with how other segment evaluation failures are handled.

Rust behavior

confidence-resolver/src/lib.rs ~L1290-1292:

if visited.contains(&segment.name) {
    fail!("circular segment dependency found");
}

The fail!() macro returns a ResolveError::Internal, which surfaces as an error to the caller.

Java behavior

AccountResolver.java ~L608-636:

if (visitedSegments.contains(segmentName)) {
    throw new InternalServerException(
        "Segment %s has a circular dependency".formatted(segmentName));
}

Java also throws, but the exception is caught in the surrounding segmentMatches() method:

} catch (RuntimeException error) {
    logger.error("Error during targeting for flag {}", flag, error);
    return false;  // returns false → NO_SEGMENT_MATCH
}

The circular dependency is logged as an error but treated as a segment evaluation failure, returning false. This causes the rule to be skipped and the flag resolves with NO_SEGMENT_MATCH.

Affected spec tests

• circular_segment_dependency

[nicklasl]

In practice though — both Rust and Java end up giving the application a default value. The difference is:

• Java (NO_SEGMENT_MATCH): The circular-dependency flag resolves normally with empty variant/value. Other flags in the same batch resolve fine. Providers return the default value with a standard "no match" reason.
• Rust (InternalError): The entire resolve_flags call errors out. All flags fail, not just the broken one. Providers return default values with an ERROR reason.

For a single-flag resolve, the end result is similar — the app gets its default value either way. But in a batch resolve, one misconfigured flag with circular segments would take down resolution of every other flag in the request. That's the real problem.