feat: add v4 evaluation response types to provider library

[lourens-octopus]

Resolves BMBB-747. Java counterpart of openfeature-provider-dotnet#92, which resolved the .NET equivalent, BMBB-674.

What

Adds the OctoToggle v4 evaluation-response contract as types only — nothing is hooked up, and the v3 path is untouched. The provider only ever deserializes this response (GET api/toggles/evaluations/v4 → array of ServerSideEvaluation); OctoToggle resolves the server-side conditions itself and sends only the client-side ones, keyed by a camelCase type discriminator.

New in src/main/java/com/octopus/openfeature/provider/v4/: ServerSideEvaluation (server-resolved value/reason, or deferred evaluationKey/rules), ClientSideRule, the polymorphic ClientSideCondition and its three variants, UnknownCondition, and ConditionTypeNames.

Decisions

• Types are package-private in a v4 sub-package — Java's nearest equivalent to internal. The public API is unchanged: still just OctopusProvider, OctopusConfiguration and ProductMetadata.

  Worth knowing for the follow-up, since Java package access isn't hierarchical: …provider cannot see these types. This assumes the v4 evaluation logic will live in the v4 package too, exposing a single public entry point when it lands. Nothing needs one yet, so this PR adds none.

• Unknown conditions degrade gracefully. An unrecognised or absent discriminator deserializes to UnknownCondition rather than failing the whole response, so a condition type introduced by a newer server is treated as "not met" by an older client. Jackson's @JsonTypeInfo(defaultImpl = …) covers both cases, so .NET's custom converter has no equivalent here.

• Client-side condition evaluation is left unimplemented, per the ticket — it lands in the follow-up. The types are named for what they become there, so that PR is not a rename of everything introduced here.

• TestObjectMapper is a test-only shim exposing the package-private OctopusObjectMapper, so the v4 tests exercise the production mapper rather than a copy that could drift from it.

Tests

ServerSideEvaluationDeserializationTests — 15 tests covering each condition type, mixed arrays, both response shapes, the unknown- and missing-discriminator fallbacks, a missing required property, extraneous properties, and list immutability. Two of them pin down casing: the discriminator property name is case-insensitive, its value is matched exactly.

230 tests pass, 0 failures. Public API surface confirmed unchanged via javap.

Unrelated to this PR: the POM doesn't pin maven-surefire-plugin, so mvn test can silently run zero tests on Maven builds whose default surefire can't discover JUnit 5. Worth pinning separately.

🤖 Generated with Claude Code

[lourens-octopus]

Superseded by #52 — same commit, same branch renamed lourens/bmbb-674 → lourens/bmbb-747 to match BMBB-747. GitHub closed this PR automatically when its head branch was renamed; it had no reviews or comments.