Unchanged BIT projections return inconsistent protocol types with COUNT and a CTE

Description
MariaDB Server 12.3.2 changes the protocol type of an unchanged BIT projection when COUNT(DISTINCT v) is replaced with COUNT(v) in a grouped CTE query. More directly, two identical projections of the same CTE expression in the COUNT query receive different types: the first is `MYSQL_TYPE_LONG`, and the second remains `MYSQL_TYPE_BIT`.

The aggregate counts and group values are otherwise correct. This report concerns server result type/metadata consistency, not an incorrect COUNT value.

How to repeat

CREATE TEMPORARY TABLE metadata_bit (k BIT(8), x LONGTEXT);

INSERT INTO metadata_bit VALUES

    (b'01001101','one'),(b'01001101','two'),(b'01000011','three');

WITH c AS (SELECT k AS a,k AS b,x AS v FROM metadata_bit)

SELECT a AS k1,COUNT(DISTINCT v) AS n,a AS k2 FROM c GROUP BY a;

WITH c AS (SELECT k AS a,k AS b,x AS v FROM metadata_bit)

SELECT a AS k1,COUNT(v) AS n,a AS k2 FROM c GROUP BY a;

_ Expected result_

Both unmodified projections of `a` preserve the BIT type. Changing a separate aggregate should not turn the first copy into an integer while leaving the other as BIT. All `x` values within each group are distinct here, so the counts are also identical.

Actual result

| Statement | `k1` protocol type | `k2` protocol type | Example decoded row |

| --- | --- | --- | --- |

| COUNT DISTINCT | BIT (16) | BIT (16) | `(b'M', 2, b'M')` |

| COUNT | LONG (3) | BIT (16) | `(77, 2, b'M')` |

For the other group, the COUNT query returns `(67, 1, b'C')`. The first key uses integer decoding and the last uses BIT decoding because the server advertises different field types. The driver is following those type declarations.

The CTE intentionally includes the same source BIT column under two aliases (`a` and `b`); `b` is not projected by the outer query. Both outer projections reference `a`. This shape is retained because it reproduces the discrepancy.