An --update pass overwrites the previous WARC and leaves a page-less WACZ

[xroche]

A second crawl into the same output reopened the WARC with "wb" and truncated it. On a cache-served pass nearly every URL comes back 304, so the file that replaced the archive held revisit records whose payloads had just been deleted, and the WACZ rebuilt beside it came out with zero page rows and nothing left to replay.

The writer now builds into a sibling .tmp whenever an archive is already there, and swaps it in at close only if the result can stand on its own. A pass that only revisited URLs it did not re-download keeps the previous .warc.gz, .cdx and .wacz, and logs why. A first crawl or a cacheless pass still writes in place.

Two related bugs turned up while building it. hts_rename_over() unlinks its destination when the source is missing, so a failed segment open under --warc-max-size deleted the previous run's segment; every temp is now checked present before the first rename, and a run that lost a record or a segment does not swap at all. warc_rotate() also advanced w->seg before the open that could fail, leaving the counter naming a file nobody created.

Tests 73 and 74 were pinning the old behaviour, 73 by requiring the update pass to have overwritten the archive and 74 by driving its second pass with -C0 to sidestep this bug. 73 now archives its second pass under a name of its own, which is the recovery the error message suggests; 74 keeps -C0 as the case that legitimately replaces. The two new tests fail against the pre-fix engine.

What --update should mean for WARC output is still open, and refusing has a cost: a pass that fetches new pages alongside its 304s loses those captures too, because there is nowhere valid to put them until that is settled. Options and evidence are in #759.

Closes #759

[xroche]

CodeQL's two cpp/path-injection alerts are the two master already carries, at the same call sites. They re-reported because the diff shifted the lines:

alert	in this PR	on master
251	htswarc.c:1292, the warc_rotate() FOPEN	htswarc.c:1268
250	htswarc.c:1514, the warc_open() FOPEN	htswarc.c:1477

Same two FOPEN calls, with one extra hop through warc_open_path(). No new call site, no new source.

The taint, traced rather than taken from the alert text. CodeQL names its sources as a command-line argument and an environment variable, and that holds up:

• warc_open()'s path comes from StringBuff(opt->warc_file). The only writers of that field are htscoremain.c:1773 (argv[na]), the WARC_AUTONAME constant at 1801 and 1803, copy_htsopt() at htscore.c:3744, and the "" init at htslib.c:6031. None of them carries network data.
• The auto-name and bare-basename cases prepend StringBuff(opt->path_html), which is -O. Its only non-test writers are the "" init and copies of another httrackp.
• warc_rotate()'s name is w->seg_base (split from the same path), %05u of w->seg, and w->seg_ext, which is a static ".warc.gz" or ".warc".

One place remote content does reach this, worth stating because it is where the segment-per-run work would show a problem if there were one: w->seg advances when w->offset >= w->max_size, and w->offset is ftell(), so a hostile server can influence how many segments a run creates by sending large bodies. That influences the count, not the characters. %05u of an unsigned yields digits, so there is no way to reach a separator or a traversal component through it, and that holds for crawl-00001.warc.gz too.

Dismissing both as the same accepted class as the other twelve open cpp/path-injection alerts, with this trace as the recorded reason.