fix(table/dv): read deletion vectors by content_offset when the file is not a Puffin container

[sevbanbayrak]

Fixes #2070

Problem

Databricks writes deletion vectors for IcebergCompatV3 (UniForm) tables as a Delta deletion_vector_<uuid>.bin file: a one-byte version prefix followed by deletion-vector-v1 blobs, with no Puffin header or footer. The manifest entry is well-formed (file_format=PUFFIN, referenced_data_file, content_offset, content_size_in_bytes point at a valid blob; length, magic D1D33964 and CRC-32 check out). ReadDV/ReadDVs opened the file with puffin.NewReader and failed with puffin: invalid header magic.

The Java reference reader (BaseDeleteLoader.readDV) reads these tables because it never consults the Puffin footer: it reads content_size_in_bytes bytes at content_offset and deserializes the blob.

Change

• puffin: NewReader wraps the header-magic and too-small errors in a new sentinel ErrNotPuffinFile so callers can detect "no Puffin container" with errors.Is. Error messages keep their existing text.
• table/dv: when the DV file is not a Puffin container, ReadDV/ReadDVs fall back to reading the blobs directly at content_offset (readBareDVs), matching Java. DeserializeDV still verifies the blob's length, magic and CRC-32, and the decoded cardinality is validated against the manifest record_count. The footer-only checks (blob type, referenced-data-file property, cardinality property) cannot be performed and are skipped with a slog warning. Real Puffin files keep the existing strict path unchanged.
• Tests: TestReadDVBareBlobWithoutPuffinContainer (single blob, two blobs in one bare file, cardinality mismatch, range beyond file); TestReadDVInvalidPuffin now asserts the direct-read error.

Verification

• go test ./puffin/ ./table/dv/, go vet, make lint (0 issues).
• Against a real Databricks Unity Catalog IcebergCompatV3 table (Iceberg format-version 3) read through the UC Iceberg REST catalog with vended credentials, after a 1,020-row DELETE and a 1,020-row UPDATE produced one DV (total-delete-files=1, total-position-deletes=2040): Scan().ToArrowRecords returns 968,980 rows with 119,960 / 1,020 rows carrying the updated markers, identical to the SQL result. Copy-on-write and non-DV tables on the same catalog are unaffected.