fix(arrow-data): align struct null validation with parent offset

[linhongyu510]

Which issue does this PR close?

• Closes Struct ArrayData non-nullable child validation ignores parent offset #10951.

Rationale for this change

For a struct with a non-zero parent offset, visible parent row i maps to child row offset + i. Nullability validation compared the visible parent null buffer against the unsliced child null buffer, so it could reject masked child nulls and accept visible child nulls.

What changes are included in this PR?

• Slice each struct child to the parent-visible window before validating non-nullable fields.
• Add a regression test covering both the correctly masked and incorrectly unmasked cases.

Are these changes tested?

Yes. TDD evidence on main at c134baf8f:

• Before the production change, the focused regression failed because the correctly masked child null was rejected.
• After the change, the focused regression passes.
• cargo test -p arrow-data --lib: 56 passed.
• cargo fmt --all -- --check: passed.
• cargo clippy -p arrow-data --all-targets -- -D warnings: passed.
• git diff --check: passed.

Are there any user-facing changes?

Yes. Validation now correctly accepts child nulls masked by a sliced struct parent and rejects child nulls visible through a non-null parent row. There are no API changes.

AI assistance

I used AI assistance to investigate the validation path, implement the focused test and fix, and prepare this description. I reviewed the complete diff and verified the behavior with the commands above.

[Jefffrey]

i feel we can modify validate_non_nullable to take in the child nulls, which we can slice here, instead of slicing the entire child which clones it

[linhongyu510]

Addressed the review in 10a396f: validate_non_nullable now receives the relevant child NullBuffer, and Struct validation slices only that bitmap at the parent offset instead of cloning the full child ArrayData. cargo test -p arrow-data passed (56 unit + 13 doctests), plus workspace fmt and Clippy with -D warnings.

[Jefffrey]

thanks @linhongyu510