MergeRecords FieldMap cannot express NULL values (Value: String! + client .toString() crash)

## Summary

A record-merge FieldMap cannot set a survivor field to NULL, and attempting it crashes client-side:

1. The GraphQL input type declares `FieldMapping.Value: String!` (non-null), so NULL is not representable on the wire.
2. GraphQLDataProvider serializes the FieldMap with `Value: o.Value.toString()` (packages/GraphQLDataProvider, `MergeRecords`), which throws `Cannot read properties of null (reading 'toString')` when a caller legitimately passes `Value: null` — core's `RecordMergeRequest.FieldMap` is typed `{ FieldName: string; Value: any }[]`, so null is a valid value there.

## Impact

Merge UIs that let users cherry-pick field values from the losing records cannot honor a pick of an empty/NULL cell — the workaround is sending `''`, which writes an empty string instead of NULL (wrong for non-text columns like dates/numbers, where '' then round-trips through BaseEntity.Set coercion).

## Suggested fix

- MJServer: `FieldMapping.Value` → `@Field(() => String, { nullable: true })`.
- GraphQLDataProvider: `Value: o.Value == null ? null : o.Value.toString()`.
- Provider merge path already applies FieldMap via `survivor.Set(FieldName, value)`, which handles null.

Lower priority than #3091/#3092 — those make the mutation unusable; this one limits its expressiveness. Found while building a record-merge UI on the CDP project (Blue Cypress).

Inspect the FieldMapping input declaration in MJServer and the MergeRecords serialization in packages/GraphQLDataProvider. Verify that a null FieldMap value is accepted without a client crash and reaches the existing survivor.Set(FieldName, value) merge path as NULL.

Written by the indexing model from the issue text.