test(admin): use json payloads in the heartbeat metadata tests (#7692) - #7846

Approved — this is exactly the fix needed and it unblocks master.

The two assertions now use a payload the storage contract accepts:

first.setInstanceInfo("{\"version\":\"1.0\"}");
...
assertEquals("{\"version\":\"1.0\"}", cached.getInstanceInfo());

That is correct on both branches. The insert path runs InstanceInfoUtils.normalize, which returns an already-compact JSON object unchanged, so the first assertion holds; the containsKey path stores the reported value raw, so the second heartbeat yields {"version":"2.0"} verbatim. The blank-beat case then keeps the previously stored object, which is the behaviour the test exists to protect.

The original intent of these tests — metadata is refreshed when the same identity reports again — is fully preserved; only the incidental payload literal changed. That was the right call rather than relaxing testInvalidOptionalInformationDoesNotStopHeartbeats, which documents a deliberate contract ("not-json" → "{}").

One note, non-blocking: the containsKey branch of handleBeatInfo still stores the reported value without normalizing, while the insert branch normalizes. With JSON payloads the two agree, so this PR is not affected — but the asymmetry is still there and is what made the original tests drift. Worth a follow-up on #7785 rather than here.

CI is green on this branch (the same suite that was failing), so this should turn master green once merged.