fix(metadata): align direct-upload keys to canonical dg-* namespace

[sscarduzio]

Summary

_upload_direct (the path taken by non-delta-eligible files like .sha1 / .sha512) was writing user-metadata with bare underscored keys (original_name, file_sha256, compression) while delta and reference uploads correctly used the canonical dashed namespace (dg-original-name, dg-file-sha256, dg-compression).

Downstream consumers — most visibly the DeltaGlider Proxy — only recognised the dashed form, so every .sha1 / .sha512 listing on a bucket holding deltaglider-uploaded files produced this in the proxy's logs, for every single object on every LIST call:

WARN PATHOLOGICAL | Missing/corrupt DG metadata for
bucket/key.sha1 — falling back to passthrough.
This file was likely copied without --metadata flag.
Error: Storage error: Missing dg-original-name

This patch aligns the writer to the canonical scheme. The read path stays backward-compatible with already-stored bare-keyed objects via resolve_metadata so no re-upload is required for the millions of .sha files already in production buckets.

Changes

Writer

• _upload_direct emits metadata using f"{METADATA_PREFIX}{key}", matching the pattern delta/reference uploads already use.

Read-path alignment

• METADATA_KEY_ALIASES now lists compression and source_name so resolve_metadata works for both fields uniformly.
• Replaced bare metadata.get(...) lookups with resolve_metadata calls in:
  • DeltaService.get (dispatch on compression == "none")
  • DeltaService.delete + _delete_delta (extract original_name)
  • The recursive-delete listing path (identify direct uploads)
  • client.list_objects_v2 (FetchMetadata extras)
  • client_operations.stats.get_object_info

Tests

• tests/unit/test_metadata_aliases.py (new, 11 tests) — pins the alias table contract: new dashed keys resolve, legacy bare underscored keys resolve, legacy hyphenated keys resolve, dashed wins when both present, empty strings count as missing, every field has both the new and the legacy form in its alias tuple, compression and source_name are present.
• test_direct_upload_emits_dashed_namespace in tests/unit/test_core_service.py — pins the writer to emit only dg-* keys; will catch any future regression on this exact bug.
• Existing tests at test_s3_compat.py and test_recursive_delete_reference_cleanup.py using the legacy bare compression: "none" form still pass unchanged — proving the dual-scheme read contract holds.

Full unit suite: 87/87 pass, mypy clean, ruff clean.

Backward compatibility

Scenario	Behaviour
Read pre-v6.1.2 direct upload (bare keys)	✅ Still recognised via alias table
Read post-fix direct upload (dashed keys)	✅ Recognised via primary alias
Both schemes present on same object	✅ Dashed wins (test pinned)
Pre-v6.1.2 → upgrade → pre-v6.1.2 (downgrade)	✅ New uploads still work; old reader matches compression/original_name directly

No migration required.

Test plan

• uv run pytest tests/unit/ — 87/87 pass locally
• uv run ruff format --check src/ tests/ — clean
• uv run ruff check src/ tests/ — clean
• uv run mypy src/deltaglider — Success
• CI green on the PR
• Verify against DeltaGlider Proxy logs after a new upload — no more PATHOLOGICAL warning

🤖 Generated with Claude Code