fix(gc): don't act on partial storage listings

[MilagrosMarin]

Fixes three compounding completeness bugs in GarbageCollector.list_hash_paths and list_schema_paths that could cause collect(dry_run=False) to silently delete live external-store files. Follow-up to the completeness-layer discussion on #1478.

Changes

1. str.replace(full_root, "") corrupts paths when the root string recurs

Both list_*_paths derived relative paths as file_path.replace(full_root, "").lstrip("/") (gc.py:209, 256). str.replace replaces every occurrence, so if full_root reappears later in file_path — e.g., S3 bucket "store" + schema "store" → full_root="store/" recurs in "store/_hash/store/xxx" — the middle occurrence gets stripped too. The resulting relative key doesn't match the reference-side shape, so a live file falls into the orphan set. Real live files aren't destroyed (the corrupted key fails backend.exists()), but real orphans in affected schemas never get reclaimed. Uses file_path[len(full_root):] (prefix slice) instead.

2. fs.size handling diverged silently between the two functions

list_hash_paths wrapped stored[relative_path] = fs.size(file_path) in except Exception: pass — dropping the file from stored entirely, so an orphan invisible to collect() and quietly retained forever. list_schema_paths used except Exception: stored[relative_path] = 0 — keeping it visible but counting 0 bytes toward bytes_freed. Neither logged. Both now keep the entry at 0 and log a warning.

3. fs.walk errors returned a partial listing with no signal to collect()

An S3 permission drop, expired token, transient 5xx, NFS unmount, etc. all present to collect() as an empty (or partial) stored dict. orphaned = stored - referenced then computes to set(), and the stats dict reports orphaned_hash_paths: 0 — indistinguishable from a genuinely clean store. A user running nightly GC would see "nothing to reclaim" while their listing was silently failing.

Adds a _scan_errors: list[str] instance attribute on GarbageCollector. list_*_paths append to it when a walk fails (in addition to the existing logger.warning). collect() resets it at the start and, before deleting, refuses with a clear DataJointError if it's non-empty. The stats dict now includes scan_errors: list[str] — empty on clean runs.

Behavior changes

• collect(dry_run=False) raises DataJointError when a listing walk failed. Real-store tests unaffected; would only surface in tests that mock fs.walk to raise (none currently do).
• fs.size errors on the hash side now keep the entry at 0 (was: drop). More conservative for orphan detection.
• New scan_errors: list[str] field in the returned stats dict. Additive; existing tests that check specific keys still work.

Verification

Applied and tested locally in an isolated worktree:

• tests/integration/test_gc.py: 39/39 pass unchanged → 42/42 pass with fix + 3 new TestScanErrorGuard tests (reset-between-calls, refuse-to-delete-on-scan-error, scan_errors-in-stats).
• Unit tests: 319/319 pass.
• Full integration: 626 pass / identical to baseline (1 pre-existing failure in test_tls.py, 5 pre-existing errors in test_university.py — both unrelated to gc.py).

Scope note

Findings #1 (_references swallows per-table exceptions) and #2 (Codec.referenced_paths silent [] on bad input) from #1478 are structurally similar but touch different code paths (_references() and the codec API surface). Kept out of this PR to keep the scope tight — they could adopt the same _scan_errors mechanism in a follow-up.

[dimitri-yatsenko]

Reviewed the full diff and traced list_*_paths, collect(), and _full_path(). This is a solid, well-scoped safety fix — the exception ordering (FileNotFoundError before Exception so a missing section isn't misrecorded as a scan error), the guard placement (reset at the top of collect(), checked before any deletion, dry_run=True reports without raising), and the copy-on-return of scan_errors are all correct. The fs.size→0 unification fails in the safe direction (keeps the file visible rather than silently dropping it).

Two non-blocking suggestions, both inline. Neither needs to hold up merge — they'd be equally fine as a quick follow-up, consistent with the deferred-scope note on the two datajoint-python#1478 findings.

1. The prefix-slice in change 1 relies on an invariant that isn't enforced for custom storage adapters.
2. Change 1 (the headline path-corruption bug) has no regression test.

Details on each below.

[dimitri-yatsenko]

Following up on my earlier review — I'm withdrawing both suggestions:

1. Prefix-slice / custom adapters: Retracted. I traced the deletion path: list_*_paths retains only the derived relative key, and deletion reconstructs the target via _full_path(key), so a mis-derived key would round-trip to a non-existent path rather than touch a live file — no data-loss risk. The invariant also holds by construction for every built-in backend, and the prefix-slice is a strict improvement over the previous .replace(). My original framing overstated the severity; nothing to change here.

2. Regression test for the recurring-root case: Withdrawing this too — the fix is straightforward and the scenario is narrow; not worth holding the PR or churning the suite over.

The exception ordering (FileNotFoundError before Exception), the scan-error guard before deletion, and the safe-direction fs.size handling are all correct. LGTM — approving. Nice, well-scoped safety fix.