fix(arrow-avro): fix split sync marker assembly and validate per-block sync markers

[ranflarion]

Which issue does this PR close?

• Closes arrow-avro: sync marker assembled incorrectly when it splits across decode() calls #10494.
• Closes arrow-avro: validate per-block sync markers against the file header #10495.

Rationale for this change

Both BlockDecoder and HeaderDecoder assemble the 16-byte sync marker with an offset derived from the size of the incoming fragment (sync[16 - to_decode..]), which only works when all 16 bytes arrive in one decode() call; a marker straddling a chunk boundary gets scrambled (#10494). For HeaderDecoder this is live today: a header larger than one fetch whose trailing marker straddles the boundary yields a garbled Header::sync(), the async reader's sync marker scan never matches, and a valid file silently reads as an empty stream.

With assembly fixed, Block.sync becomes trustworthy, enabling the validation the Avro spec intends the marker for: both readers now compare each block's trailing marker against the file header's and reject a mismatch, matching the Java reference reader (DataFileStream throws Invalid sync!) (#10495). This continues the recent hardening of the container decode path (#10237, #10407). Without it, a desynced or corrupted stream can decode silently into wrong values; avro-deflate block data is raw DEFLATE with no checksum, so this is a real silent-corruption window with transiently faulty object stores.

What changes are included in this PR?

• BlockDecoder and HeaderDecoder fill the sync marker from the front using the consumed count (offset = 16 - bytes_remaining).
• The sync Reader and the async reader error with ParseError("Avro block sync marker does not match file header") when a flushed block's marker differs from the header's.

Are these changes tested?

• A BlockDecoder unit test feeds a block in every chunk size from 1 byte up and asserts the assembled marker; it fails on main.
• Both readers get a test that flips the final byte of alltypes_plain.avro (the last block's sync marker) and asserts the read fails; on main the flip is accepted silently.
• Existing suites pass unchanged, including the roundtrip and range-read tests.

Are there any user-facing changes?

Corrupt files that previously decoded silently (or, for the header case, silently produced an empty stream) now error, matching the Java reader. Appended files reuse the file's marker, so any file the reference reader accepts still reads fine.