Fix racecheck in parquet page_string_decode kernels

[davidwendt]

Description

Fixes a racecheck found in the weekend compute-sanitizer run in the parquet page_strings_decode.cu kernels totalDeltaByteArraySize and compute_delta_length_page_string_sizes_kernel. Adds a warp.sync() before the call to the setup_next_mini_block() utility which runs only on warp lane=0.

https://github.com/NVIDIA/cudf/actions/runs/31878600604/job/94998078592#step:5:2953

[ RUN      ] ParquetStringsTest.ReadLargeStrings
========= Warning: Race reported between Read access at cudf::io::parquet::detail::<unnamed>::totalDeltaByteArraySize(const unsigned char *, const unsigned char *, int, int)+0x9910 in page_string_decode.cu:455
=========     and Write access at cudf::io::parquet::detail::delta_binary_decoder::setup_next_mini_block(bool)+0x9be0 in delta_binary.cuh:208 [1250960 hazards]
========= 
[       OK ] ParquetStringsTest.ReadLargeStrings (77563 ms)

The change was introduced in PR #23314 which rewrote the delta decode loops in cpp/src/io/parquet/delta_binary.cuh and cpp/src/io/parquet/page_string_decode.cu to decode one warp-size pass at a time. That refactor introduced the pass-by-pass loop pattern in totalDeltaByteArraySize and the DELTA_LENGTH_BYTE_ARRAY string-size kernel where all lanes read current_value_idx without a synchronizing warp.sync() before lane 0 advances it in setup_next_mini_block, causing the race.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.