Cache repair deletes the old cache before a rename it never checks

[xroche]

The two zip-repair paths still hand-roll the unlink-then-rename idiom that #754 unified everywhere else, in the worst order:

src/htscache.c:1072

UNLINK(name);
RENAME(.../hts-cache/repair.zip, name);
cache->zipInput = hts_unzOpen_utf8(name);
hts_log_print(opt, LOG_WARNING, "Cache: %d bytes successfully recovered in %d entries", ...);

src/htscoremain.c:2194 is the same block in the -#R CLI path, ending in the same "successfully recovered" line on stderr.

The destination is removed first and the rename result is discarded, so a rename that fails leaves no cache at all: the recovered entries sit in hts-cache/repair.zip, a name nothing reads, hts_unzOpen_utf8 returns NULL, and the user is told the recovery worked. hts_rename_over() does the right thing here (it only removes the destination for a failure the unlink can fix, since #779) and returns a value worth branching on.

Found while auditing the hts_rename_over() call sites for #779. Unlike those four, these two ignore the rename outcome entirely.