Bitpacked runs being longer than necessary when writing Parquet files

[Neute]

Hey everyone, I have a question regarding DuckDB's behaviour when writing Parquet files using the hybrid bitpacking - rle / plain dictionary encoding.

Consider the following example, tested with duckdb version 1.5.2:

copy 
(select * from 
   (values ('Hello'), ('Goodbye'), ('Hello'), ('Goodbye'), ('Hello'), ('Goodbye'), ('Hello'), ('Goodbye'), ('Hello'), ('Goodbye'),('Hello'), ('Goodbye'), ('Hello'), ('Goodbye'))
)
to 'test.parquet';

DuckDB will write a parquet file containing a single bitpacked run with a size of 256 elements, even though a run with 16 elements would have sufficed. Is this intentional?

I haven't found details in the Parquet spec as to whether this is allowed or not, but there is the following quote which could be interpreted as having longer than necessary bitpacking runs not being intentional:

For data pages, the 3 pieces of information are encoded back to back, after the page header. No padding is allowed in the data page

Source