The string kinds of parquet_column (PK_STRING, PK_STRING_VEC), which are the one place
the type-erased storage is not a Fortran array.
Per DD1 a string column embeds a parquet_string_column — already a self-contained
offsets + payload + validity store — and delegates to it rather than duplicating variable-
length storage or hoisting string validity into the column bitmap. That is why these
procedures are hand-written while every array kind's equivalents are generated: they are
delegation, not array indexing.
PK_STRING_VEC uses one string store for the whole column, flat-indexed
(i-1)*width + e (RF6/s1). One store rather than width stores means a single set of
offsets and one payload buffer, and — because the layout is element-major within a row — one
row's whole vector stays contiguous, which is what row access and append-row want.
There is deliberately no data_ptr for the string kinds: their storage is not a plain
Fortran array, so there is nothing kind-matched to alias. Use string_column to reach the
embedded store (and its zero-copy view/view_slice handles) instead.