Add binary-serialization upgrade test (#4515)

[jeremydmiller]

Follow-up to #4578 (binary event serialization Phase 1).

What

Adds binary_serialization_upgrade_tests.enabling_binary_serialization_on_existing_store_still_reads_old_json_events_and_appends_new_binary — proves the headline coexistence-design promise on a real upgrade path that #4578's existing tests don't quite cover:

1. Phase 1. Build a DocumentStore against a fresh schema with no binary serialization wired, append JSON-only events. Dispose.
2. Phase 2. Build a second DocumentStore against the SAME connection + SAME schema, with opts.Events.UseMemoryPackSerializer() as the only configuration delta. Append binary events (MemoryPack) to the same stream.
3. Read the whole stream back — both JSON-serialized rows (Phase 1) and binary-serialized rows (Phase 2) replay in correct order with monotonic version numbers ({1, 2, 3, 4}).
4. Append one more JSON event from Phase 2 — proves the JSON path still works in a binary-enabled store, on the same stream (version becomes 5).
5. Inspect raw data / bdata columns to verify the row-level discriminator: Phase 1 rows have bdata = NULL, Phase 2 binary rows have bdata != NULL, the Phase 2 JSON-typed row has bdata = NULL.

Why a new test

#4578's pre_existing_json_rows_still_read_after_feature_is_in_place only covered a single store with both modes. This test exercises the two-store upgrade story — a fresh DocumentStore / EventGraph / EventStorage for Phase 2 must pick up the existing data + handle the format switch on the same physical stream. That's the path a real user takes when they enable the feature on a deployed system.

Result

• New test passes locally on first run.
• Full Marten.MemoryPack.Tests suite still 6/6.

🤖 Generated with Claude Code