chore(release): bump version to 0.7.6

[divyasinghds]

Release 0.7.6 — bumps __version__ (0.7.5 → 0.7.6).

Included since v0.7.5

• feat(backfill): metadata backfill runner — GET dataset → recompute → send to backend (#378 send side) #393 — feat(backfill): metadata-backfill runner (tracebloc-backfill entrypoint) + APIClient.get_dataset_metadata/send_metadata_backfill + Database.list_registered_runs. The send side of the pre-cutover metadata backfill (pairs with backend #1166/#1198, client fix(objdet): resolve annotation by stem so extension-bearing filename works (#379) #380).
• fix(validators): stop doubling "Validator" in log lines (D1) #392 — fix(validators): stop doubling "Validator" in validation log lines (D1).

Why now

The published v0.7.5 image predates #393, so it lacks the tracebloc-backfill entrypoint the client chart's backfill hook invokes. Cutting 0.7.6 produces an ingestor image that carries it.

Release steps (after merge)

1. Merge this PR to develop.
2. Push tag v0.7.6 → release-image.yml builds + signs the multi-arch image and publishes ghcr.io/tracebloc/ingestor:0.7.6 (and updates floating :0.7 / :0).
3. Promote develop → master for the PyPI package (publish-master.yml), per the usual flow.

No code changes beyond the version bump.

🤖 Generated with Claude Code

---

Note

Low Risk
Small validator behavior fix plus version bump; no auth, data, or API surface changes beyond more reliable validation messaging.

Overview
Release 0.7.6 bumps __version__ from 0.7.5 to 0.7.6.

Image resolution auto-detection no longer uses the first file in glob order blindly. ImageResolutionValidator walks the image list and sets expected_resolution from the first file that actually reads successfully. That way a corrupt file listed first cannot turn a too-small dataset into a misleading “auto-detection failed” result that varied by OS/filesystem ordering.

A new test test_floor_wins_when_corrupt_file_is_first forces corrupt-before-readable ordering (via monkeypatched _get_image_files) and asserts the minimum-size floor error still wins while corrupt paths stay in invalid_files metadata.

^{Reviewed by Cursor Bugbot for commit d1c7b1b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[shujaatTracebloc]

Pushed a fix for the red pytest — the failure was not the version bump.

test_too_small_result_still_reports_corrupt_files was order-dependent. Auto-detection in ImageResolutionValidator.validate() read only image_files[0], so when the corrupt broken.jpg came first in glob order (deterministic on the Linux CI, not on macOS — hence green locally, red on CI) it returned None, expected_resolution stayed unset, and _validate_image_resolutions bailed with "auto-detection failed" before the min-size floor check could run. Reproduced it deterministically by forcing the corrupt file first.

Fix (d1c7b1b): auto-detect from the first readable image instead of [0]; if none are readable, the honest "auto-detection failed" still surfaces. Added an order-independence guard test that forces the corrupt file first (fails pre-fix, passes post-fix). Full suite green locally (1867 passed, 1 xfailed).

Since #394 merges into develop, this lands the fix on develop in the same merge.