Lifecycle of a parquet_table: opening one from a file, starting an empty in-memory one,
destroying one, the blocked intrinsic assignment, and the slot/row bookkeeping that adding a
column goes through.
The one structural rule everything here exists to protect: the column store lives behind the
cache POINTER, never an allocatable component. That is what lets a read accessor stay
intent(in), and what keeps a pointer handed out by %col valid without the caller having to
declare the table target -- the pointer targets heap owned by the cache, not the dummy
argument, so F2018 15.5.2.4's "pointer to a dummy's target becomes undefined on return" rule
never applies to it. The price is that intrinsic assignment must be blocked (two tables sharing
one cache would double-free it), which table_assign_guard does.