refactor: split json parsing/translation for future-proofing client/server distinction

[beekld]

As discussed in a previous PR, this splits apart the parsing and translation for FDv2 changesets, so that the server-specific code is separate from the shared code. This will be needed once we add client code later.

I went with passing around JSON objects everywhere, rather than passing in a translator, because 1) it's simpler, and 2) it's more like Java, which has advantages for understanding code across codebases.

---

Note

Medium Risk
Moderate risk because it changes the FDv2 ingestion pipeline and error/forward-compatibility behavior (unknown kinds and JSON deserialization), which could affect store updates and sync reliability.

Overview
Splits FDv2 event handling into two phases: the shared FDv2ProtocolHandler now only accumulates raw changes (kind, key, version, and JSON object) and emits an FDv2ChangeSet without deserializing flags/segments.

Adds a server-side TranslateChangeSet step that converts raw FDv2 changes into typed ItemDescriptor<Flag|Segment> changes for application, warning/skip on unknown kinds and aborting the whole changeset on deserialization failure.

Introduces a generic data_model::ChangeSet<T> + shared ChangeSetType, updates MemoryStore::Apply and FDv2SourceResult to consume ChangeSet<ChangeSetData>, and wires translation into FDv2 polling (including a new translation-failure interrupted error). Tests are updated and new translator unit tests are added, including the behavior change that unknown kinds now pass through the protocol layer.

^{Reviewed by Cursor Bugbot for commit 854edbd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[kinyoklion]

I think this is a change from a JSON parse error.

if (!result->has_value()) {
    return tl::make_unexpected(Error::JsonParseError(
        "flag '" + put.key + "' object was null"));
}

Where I still think we would want the data source level to treat this as malformed JSON for reconnect triggering purposes/status reporting.

[beekld]

I think this is the same behavior as Java:

https://github.com/launchdarkly/java-core/blob/f4719ecf55d11f2e16a34b904349f98c469213ba/lib/sdk/server/src/main/java/com/launchdarkly/sdk/server/FDv2ChangeSetTranslator.java#L74

I don't really think either one is more "correct" (unless the spec covers this case). But I'm happy to change it if you feel strongly.

[kinyoklion]

I am trying to think what really should happen if this case was encountered. I am not sure either is amazing. I am fine with this for the moment.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 854edbd. Configure here.}