See test NonSharedPrimitiveCollectionsQueryCosmosTest.Array_of_byte_array, where we incorrectly persist a byte[][] as an array of arrays (
[[1, 2], [1, 2]]) instead of an array of base64 strings. The type mapping looks correct - a CosmosTypeMapping with an ElementTypeMapping that has BytesToStringConverter. However, in the update pipeline we reach this code in GetCurrentProviderValue:

var converter = typeMapping.Converter;
if (converter != null)
{
    value = converter.ConvertToProvider(value);
}

Since the type mapping for the array has no converter (only the element one does), we skip conversion. I think that in relational we have special logic for handling JSON, so things work in some other way there. I also suspect we have similar problems elsewhere (e.g. writing parameters in queries). We may want to think holistically about how this is supposed to work - the PG provider has an array converter that composes over the element type mapping, but that may not be the right thing to do elsewhere.

Note that we have other Cosmos issues with primitive collections over value-converted elements (e.g. advanced type inference in query, #34026); we may want to consider punting on supporting that as a feature for 9.0 (and model-validate against it).