chore: allowlist Arrow IPC base64 false positives in .gitleaksignore

[msrathore-db]

Problem

The Databricks global pre-push secret scanner runs gitleaks detect over each new branch's commit range. The aws-access-token rule (which targets AKIA…/ASIA…-style keys) collides with high-entropy base64 substrings inside the Apache Arrow IPC payloads stored in the internal/rows/arrowbased/testdata fixtures ("batch": "/////5gCAAAU…").

This produces 24 false positives across 8 fixture files (diamonds.json, all_types*.json, arrays_native.json, structs_native.json). They are binary Arrow result data, not credentials — entropy ~1.5 vs ~4.3+ for a real AWS key.

All were introduced by f27a47b ("Fetch results in arrow format", #109). Because gitleaks detect fingerprints are commit-SHA-prefixed and the scan walks back through history, these re-surface on every new branch — even branches that never touch these files — forcing contributors to push with SKIP_SECRET_SCAN=1.

Fix

Commit a repo-root .gitleaksignore listing the 24 SHA-prefixed fingerprints. gitleaks detect reads this file automatically, so the false positives are suppressed permanently for all branches with no per-push workaround. This mirrors the approach already used in databricks-driver-test.

Verification

Re-running the exact pre-push scan against the introducing commit with the file present:

gitleaks detect -c gitleaks.toml --exit-code 3 --log-opts="-p -1 f27a47b…"
→ no leaks found (exit 0)

The push of this branch itself passed the pre-push secret scan with no block.

This pull request and its description were written by Isaac.