json: verify and address compatibility for cross-repo persistence consumers after refactoring #680

Parent: #642

What

The epic's "Maintain compatibility and migrate users" scope only assesses dependents inside the baselibs repo (it names score/hash and logging config as examples). score/json is also consumed as the external score_baselibs Bazel module by at least two sibling S-CORE repos that persist data through a full JSON write-then-read round trip, not just one-way parsing:

• persistency/score/kvs/kvs.cpp — the key-value-store component owns both score::json::JsonWriter and score::json::JsonParser directly. It calls writer->ToBuffer(root_obj) to persist state and parses it back later. This is exactly the "reading data from a persistence partition" scenario the epic calls out as an Assumption-of-Use boundary.
• config_management/.../config_daemon/code/json_helper/ — JsonHelper/JsonHelperImpl wraps both json::IJsonWriter and the parser behind its own interface, used by the config-daemon's parameter-set persistence (parameter_set_impl.cpp, parameterset_collection_impl.cpp).

Both are directly exposed to:

• the json writer: remove writer selection and delete the json_serialize writer #644 json writer: collapse the JSON writer backend seam into a single serializer #667 writer byte-format changes (booleans, empty-container, escaping differences change the bytes written),
• the json parser: \u escape sequences are not supported #671 \u escape bug — if either ever persists a string containing a control character, JsonWriter emits \u00XX today and the current JsonParser cannot read it back, silently breaking the round trip and potentially losing or corrupting stored data.

Neither consumer is tracked by any of the epic's other sub-issues today, and because they live in different repos, they won't be caught by bazel test //score/... in baselibs CI.

Acceptance Criteria (DoD)

• persistency and config_management are built/tested against the consolidated score/json (post Component Modification : json parser : remove parser backend selection and the nlohmann parser #632/json parser: collapse the parser indirection into a single JsonParser implementation #634/json writer: remove writer selection and delete the json_serialize writer #644/json writer: collapse the JSON writer backend seam into a single serializer #667) in their own CI, and results are captured here.
• A round-trip test (write via JsonWriter, read back via JsonParser) is confirmed to pass for both consumers using a string containing a control character — verifying json parser: \u escape sequences are not supported #671 is fixed before these consumers rely on it.
• score_baselibs release notes for the consolidated JSON library explicitly flag the writer byte-format changes as relevant to any consumer that persists JSON, so repo owners outside baselibs know to check their own persisted-data compatibility.
• If either consumer fails to round-trip correctly, the incompatibility is reported back as a blocking issue against the relevant sub-issue before JSON Library Refactoring and ASIL-B Completion #642 is closed.

How

No response.