feat: Deletion vector reader

[Shreyas220]

No description provided.

[laskoviymishka]

nice work!

this is a solid foundation for DV read support: envelope parsing is correct, puffin ReadAt integration is clean, and the Java golden test data is a great choice for cross-impl validation.

main concerns:

1. OOM from sparse keys — the gap-filling loop in DeserializeRoaringPositionBitmap can allocate billions of empty bitmaps with adversarial input (keys [0, 0xFFFFFFFF]). needs a cap or a map-based representation
2. Serialize writes empty gap bitmaps — Java only writes non-empty keys, so Go-serialized output won't match. reader-only for now but it's public — either fix or unexport
3. ReadDV cardinality trap — always passes dvFile.Count() which is 0 when unset, rejecting valid DVs
4. dvMockDataFile/strPtr missing — tests won't compile, looks like a helper file was left out of the PR
5. 4 golden files unused — especially all-container-types-position-index.bin which exercises run containers, the main cross-library bug source

left some comments.

Also general observation - we should add for serialize / write puffin x-engine compatibility e2e tests, this probably beyond this PR scope, but need to keep this in mind once we start to enable DV support.

[zeroshade]

Will defining the constant this way work for big-endian architectures or do we need to add a conditional compilation etc? Can we just use the actual uint32 value to avoid endian differences?

[Shreyas220]

change it to
DVMagicNumber uint32 = 1681511377
like here ??

https://github.com/apache/iceberg/blob/df00c156d41deddd0dc979f2867ad6f81cb0e246/core/src/main/java/org/apache/iceberg/deletes/BitmapPositionDeleteIndex.java#L36

[zeroshade]

it's super weird that the spec jumps back and forth between big and little endian representations....

[zeroshade]

does the puffin reader need a defer reader.Close()?

[Shreyas220]

puffin reader doesn't own the file IO , it gets it from caller so i would like the caller of puffin file be responsible for closing not puffin reader

let me know if you think otherwise

[laskoviymishka]

no major concerns from my side.

A few minors to keep in mind for future work on DV:

1. uint64 vs signed-with-guards. If we move to uint64 later, the pos < 0 guards and count < 0 checks go away. Probably the cleaner shape long-term.
2. X-engine compat e2e tests for serialize/write once DV write support lands. Currently reader-only, so low risk today, but we'll want Spark/Java-produced DVs decoded + Go-produced DVs read back by Spark before enabling write. This is a way bigger item, so need to do a separate research
3. maxBitmapCount is currently a package constant. If we ever hit a real table that legitimately needs more, it becomes a config knob conversation, worth a brief note in the code on where the number came from.