fix(fetch): make the .json sidecar collision guard case-insensitive

[sturlese]

Context

PR #1 (8755c3b) fixed the .json content-vs-sidecar collision but was merged before the follow-up hardening from that PR's review landed, so main still carries a residual of the same bug. This PR brings the missing fix onto main.

Bug (still live in main)

The .json → .data.json remap in download_file is a case-sensitive exact match, but ext_for returns the extension verbatim. A Drive file named CONFIG.JSON keeps ext .JSON, so its content lands at <fid>.JSON — the same path as the sidecar <fid>.json on a case-folding filesystem (macOS APFS, Windows, Docker Desktop bind mounts). The sidecar write then clobbers the content, exactly the failure PR #1 set out to close.

Fix

• content_name() now owns the content-filename decision and disambiguates against the sidecar case-insensitively (<fid>.data.JSON for an uppercase-.JSON source).
• The sidecar path is single-sourced behind sidecar_name() (was duplicated across 5 sites — reuse/altitude findings from the PR fix(fetch): stop the metadata sidecar from clobbering .json file content #1 review).
• The two sync_once guards collapse into one _is_sidecar_path() neutralization of prev_local (simplification finding), which also makes the heal path case-insensitive.

Test

New regression test test_sync_once_uppercase_json_content_does_not_collide_with_sidecar, verified to fail against the case-sensitive version now in main. Full fetch suite: 26 passed, coverage 90% (gate 75%). ruff check pipeline evals clean.

---

Found by the autonomous bughunt loop: iteration 2 detected that the merged PR #1 was incomplete (the review's own hardening commit never reached main) and re-shipped the missing fix. Dry-run mode — human merges.

🤖 Generated with Claude Code

[sturlese]

Gate: adversarial verify → one regression found and fixed (14739ed)

The gate's adversarial verifier confirmed the core fix is complete (no remaining collision, converges in one pass, converter detection unaffected) but caught a low-severity regression on case-sensitive filesystems (Linux/ext4 — the production target):

• The name-only _is_sidecar_path neutralized prev_local for any case-insensitive sidecar-name match. On a case-sensitive FS a distinct <fid>.JSON content file is not the sidecar, so it was wrongly treated as clobbered → one spurious re-download + the old file orphaned on disk. main's exact-match guard handled this cleanly.

Fix: decide the clobber by file identity (samefile), not name. An exact sidecar-name localPath is always the clobber; a case-variant is the clobber only when it resolves to the same file as the sidecar (i.e. case-folding filesystems). Added test_clobbered_by_sidecar_uses_file_identity_not_name, which locks both filesystem branches deterministically (via a samefile monkeypatch, since a case-sensitive volume can't be created on the macOS dev box).

Full fetch suite: 27 passed, coverage 89% (gate 75%). ruff check pipeline evals clean.

Gate verdict: clean after 1 fix round. Dry-run mode → open for human merge.