`JSON_LOOSE()` metadata overflow creates `BINARY(0)` and loses data

1. 1. Summary

`JSON_LOOSE()` estimates that formatting can double its input length. The
estimate is multiplied in a 32-bit `max_length`. At an argument descriptor of
2,147,483,648 bytes, the declared result wraps to zero.

Direct evaluation returns the complete eight-byte document `

`. A
view exposes the result as `BINARY(0)`, grouped materialization loses the
bytes, and strict CTAS rejects the row with error 1406. This is a
Release-visible result and schema integrity bug. No Release crash or memory
safety impact is claimed.

1. 1. Affected version

Reproduced twice in MariaDB 11.8.8 official Release and twice in an
exact-source Debug+ASan build. The checked 11.8 and main source revisions
retain the multiplication.

1. 1. Reproduction

```sh
mariadb --force -uroot -p < reproduce.sql
```

The table stores one byte. The large number is carried only by metadata from
an unselected `SUBSTRING()` branch.

Expected observations:

• direct control and trigger both return length 8 and hex
  `7B2261223A20317D`;
• the trigger view is `binary(0)`;
• the trigger grouped value reports its computed length but has empty hex;
• control CTAS stores all eight bytes;
• final trigger CTAS fails with error 1406, while the server remains alive.

1. 1. Real-world impact

Valid formatted JSON can disappear when query execution introduces a
temporary field, or a schema-producing statement can infer a zero-width
column. This makes direct SELECT, grouped/derived SELECT, view metadata, and
CTAS disagree for the same deterministic expression. Non-strict field paths
can silently persist truncated data; strict paths reject valid runtime data.

An ordinary schema owner can trigger the issue without large input, corrupt
storage, plugins, or administrative privileges.