Consider salt progress for ETA

As I suggested in https://www.openwall.com/lists/john-users/2023/11/15/2

We'd need the calculation to consider progress at processing more salts within the current batch of password candidates. Maybe instead of the actual number of candidate passwords processed, we could use a virtual number scaled by the ratio of salts processed so far. In other words, in p/s and ETA instead of the actual but lagging p, we could use p + kpc*saltn/salts. As a special case, on interrupt/restore we'd need to infer the number of previously processed salts. Another special case is "single crack" mode, where we should omit this logic.

Alternatively, as magnum suggested, we should at least mute ETA until the first block of candidates has been processed or if it matches the current time.

The issue names no files, tests, or entry points. Begin by tracing the existing candidate-progress, salt-processing, p/s, and ETA calculations in the John the Ripper source. Done means agreeing on one approach, covering interrupt/restore behavior, excluding single-crack mode, and validating the ETA behavior.