MDEV-40678 fix is incomplete: type_mysql_json still performs out-of-bounds reads on malformed MYSQL_JSON values

MDEV-40678 added two bounds checks in `plugin/type_mysql_json/mysql_json.cc`:

• inline / pointer value: `value_start >= len` rejection (`:376-378`);
• key data: `key_start + key_len > bytes` rejection (`:458`).

Several read paths in the same parser remain unchecked at HEAD:

1. `parse_array_or_object()` reads the element count (`:420`) and payload size (`:421`), rejects
`bytes > len` (`:424`), but the loop `for (i = 0; i < element_count; i++)` (`:431`) never validates
that the key/value header arrays fit in `len`/`bytes`. `key_offset = 2 * offset_size + i * key_size`
(`:447`) can exceed the buffer, and `read_offset_or_size(data + key_offset)` (`:448`) then reads out
of bounds; `value_type_offset` (`:453-455`) likewise feeds `data[value_type_offset]` read at `:371`
before any check exists.
2. `JSONB_TYPE_OPAQUE` (`:282-294`): `read_variable_length(data + 1, len, …)` (`:291`) passes `len`
although only `len - 1` bytes follow the type byte; the helper trusts its argument
(`MAX_BYTES = MY_MIN(data_length, 5)`, `:126-138`), so a malformed continuation varint reads one byte
past the buffer before the `length_bytes + blob_length` check.
3. `type.cc:160-162` (`parse_mysql`) only checks `length >= 2` and then casts `data[0]`; `data[0]` is in
bounds, so this sub-claim is weak — the real issues are the element-count/header and OPAQUE cases.

1. 1. Expected result

Any malformed MySQL-binary JSON value stored in a `MYSQL_JSON` column must be rejected without reading
outside the column value buffer.