ds001499: s3-PUBLIC content fails git-annex hash verification (ses-16 T1w) — blocks mriqc for sub-CSI2/CSI3

**Symptom.** mriqc (ndoli) fails for **sub-CSI2** and **sub-CSI3**: `datalad get` of `ses-16/anat/sub-CSI{2,3}_ses-16_T1w.nii.gz` aborts with `Verification of content failed` — git-annex downloads the `s3-PUBLIC` content and its hash ≠ the recorded annex key. The one bad file kills the whole job via `set -e` (~11 min in, before mriqc runs; `ExitCode 1:0`, MaxRSS ~1 G). sub-CSI1 and sub-CSI4 complete fine.

**Distinct from the missing-versionId fault.** This is *not* the "no S3 versionId recorded" problem that openneuroorg/openneuro#3875 tracks — here the versionId metadata **exists** (`git annex whereis` shows 3 versionId'd `s3-PUBLIC` URLs) but the content at those versions doesn't verify against the key. So the versionId (`.log.rmet`) fixer won't repair it.

Reproducible on a fresh clone:

```
f=sub-CSI2/ses-16/anat/sub-CSI2_ses-16_T1w.nii.gz
git annex lookupkey "$f" # MD5E-s1966080--ebeb7ca2a892c2d04d93a23db050c8dd.nii.gz (expected size+md5)
datalad get "$f" # get(error): ... [Verification of content failed]
```

**Upstream.** Reported on openneuroorg/openneuro#3875 (ds001499 is already listed there; added the hash-mismatch observation as distinct from the missing-versionId one). Not a mechababs/babs bug.

**Impact.** Blocks anat processing (mriqc + downstream fmriprep) for the affected subjects until the `s3-PUBLIC` content is corrected; recurs on any re-run.

Start with a fresh clone and reproduce the failure using git annex lookupkey and datalad get for sub-CSI2_ses-16_T1w.nii.gz, then compare the recorded key with the versioned s3-PUBLIC content. The issue points to openneuroorg/openneuro#3875 rather than a mechababs file; done means the affected content verifies and mriqc can proceed.

Written by the indexing model from the issue text.