1. InvalidCastException when an array-of-arrays mixes inner array shapes (Unity/Mono)

Passing this document as the dataJson of CustomEntityService.CreateEntity throws
before the request is even sent:

{ "p": [ [ {"x": 1} ], [] ] }

Also reproduces when the second inner array is all nulls instead of empty.
ReadArray infers a dictionary-array type from the first inner array, then upgrades
arrayItemType to object-array on the mismatched one, and the final
ArrayList.ToArray call throws under Mono's Array.Copy.
A small fallback resolved it for us — wrapping that ToArray call in try/catch and
falling back to the plain object-array ToArray.

2. Integers with 19+ digits (18+ when negative) silently lose precision

ReadNumber routes integers with precision of 19 or more to Double.Parse, so a value
like long.MaxValue (9223372036854775807) becomes 9.223372036854776E18 with no error.
Note that precision includes the minus sign, so negative 18-digit integers take the
double path as well. This range is easier to hit than it may look — snowflake-style
IDs (Discord, Twitter/X) are 18-19 digit integers, and long-running idle-game
currencies get there too.

What worked for us was raising the threshold to "precision < 29":

• The integer path already parses through Decimal.Parse, so only the boundary changes.
• 28 digits is the largest length Decimal.Parse can always hold exactly
  (decimal.MaxValue is about 7.9e28, a 29-digit number, so some 29-digit values
  would overflow — hence 29 is the widest safe boundary).
• Since precision counts the sign, negative values are effectively capped at 27
  digits — still comfortably covering the full long range.
• Values that fit in long still come back as long; 20-28 digit values fall through
  to decimal, which JsonWriter already emits as a quoted string when it exceeds
  IEEE754 range — so precision is preserved end to end.
• 29+ digit integers keep the existing double behavior.

We're currently carrying both changes as local patches.

Thank you!