fix: don't drop a message when a payload field is null

[blue-archon]

Problem

Incoming chat/message/attachment parsing casts the decoded payload with .cast<String, Object>(). The resulting CastMap re-casts every value to the non-nullable Object and throws a Null is not a subtype of Object cast error the first time any field is genuinely null. That aborts the whole parse and drops the chat/message/attachment for that event.

It fires on live new-message / updated-message events from both the socket (action_handler) and the method channel (FCM/UnifiedPush). Incremental sync backfills the item later, so it looks intermittent, but the real-time event is lost in the meantime. Seen on both Android and desktop during normal use, for example a null run inside an attributedBody.

Fix

Add a guarded deepNormalizeJson (lib/utils/deep_map_normalize.dart) that rebuilds maps and lists with null-tolerant reads and returns scalars (including numeric-looking strings like "1234") untouched. Route every parse site through asStringDynamicMapRequired instead of the raw cast: the method-channel entrypoints, the socket action_handler, and Chat / Message / AttributedBody fromMap.

No behavior change on well-formed payloads; a null field now parses instead of throwing.

[zlshames]

im still not sure about this deepNormalize function... you've had it on a couple of PRs already, and I feel like it's compensation for something that should be resolved somewhere else at the root. Maybe casting it properly from the start rather than having to normalize it like we are. Maybe I'm wrong, but something feels off here

[blue-archon]

You're right, that's the cleaner fix. The real bug was the cast target: .cast<String, Object>() rethrows every value as non-nullable Object, so a genuinely null field throws. .cast<String, dynamic>() is what fromMap already expects and it permits the null, with no normalize step. I swapped the casts and dropped deepNormalizeJson.