fix(parquet): bound schema nesting depth; prevent negative array offsets (FB-3438)

[lorenzhs]

Two independent stack/bounds gaps on untrusted-input paths, both found while auditing Firebolt's Arrow column converter.

schema::Unflatten: unbounded recursion

A Parquet schema is a flat list of SchemaElements whose num_children fields describe the tree, so a file can nest as deep as it has elements. Unflatten rebuilds that tree with a recursive lambda and no depth guard, one native frame per level. A schema a few tens of thousands deep overflows the thread stack while the metadata is parsed, before any consumer sees a row — an unauthenticated remote crash on any read of an attacker-supplied file.

Threads a depth counter through NextNode and rejects past kMaxSchemaNestingDepth (1000), matching the JSON reader's kMaxNestingDepth. Far above anything a real writer emits; Parquet's 3-level LIST encoding spends 2 elements per array level.

Repro: a metadata-only file (no row groups) nesting 100000 groups. Pre-patch, SIGSEGV inside Unflatten. Post-patch, Parquet schema nesting depth exceeds the maximum of 1000.

ValidateLayout: negative array offset

ValidateLayout rejects a negative length but not a negative offset, and the two are not equivalent. Every buffer-size check in the function sizes buffers by length_plus_offset; a negative offset shrinks that, so a buffer far too small for the array satisfies all of them. ArrayData::GetValues() then returns buffers[i]->data() + offset — a pointer before the buffer — to every consumer that trusted Validate().

Nothing in the format permits it, but an ArrowArray crossing the C data interface carries whatever its producer wrote: ArrayImporter::AllocateArrayData copies c_struct_->offset in unchecked, and the importer's own buffer sizing is wrong in the same direction. Validate() is where an imported array is meant to become trustworthy, so the check belongs there. Two lines beside the existing length check; the recursion into child_data covers nested arrays.