`fwb` transpiler: progress bar is one tick short when `simple = TRUE`

The `fwb` transpiler's skip count assumes `fwb()` calls `statistic` on unit weights
**twice** when `simple = TRUE`. In the current *fwb* development version it calls it once,
whatever `simple` is, so the wrapper swallows the first real bootstrap replicate's update
and the bar finishes one tick short of `R`. This might cause an issue once the development version is on CRAN, so I wanted to let you know before I submitted it.

`template_fwb_outer` sets:

```r
.progressr_skip_count <- if (.progressr_simple) 2L else 1L
```

and `template_fwb_FUN` decrements that on each call before it starts ticking. The count is
the number of times `fwb()` calls `statistic` before the `R` replicates begin.

In *fwb* 0.6.0 and earlier, `simple = TRUE` did call `statistic` twice on unit weights: the
second call existed only to detect whether `statistic` had a random component, which
determined whether the bootstrap weights could later be recovered. The development version
recovers the weights from recorded RNG streams instead, so that detection became
unnecessary and the second call was removed. There is now exactly one unit-weight call in
both cases.

An unconditional

```r
.progressr_skip_count <- 1L
```

is correct for the development version and for every release after it.

It would break *fwb* 0.6.0, though: `simple = TRUE` there would leave the second
unit-weight call to be counted as a tick, giving `R + 1` updates against a progressor with
`R` steps. So if you want to keep 0.6.0 working, this needs a version test:

```r
.progressr_skip_count <- if (.progressr_simple &&
utils::packageVersion("fwb") <= "0.6.0") 2L else 1L
```

Note that an unconditional skip count also removes the need to infer `simple`,
which the template currently does by reproducing `fwb()`'s default rule:

```r
.progressr_simple <- if (is.null(SIMPLE)) WTYPE != "multinom" else SIMPLE
```

With a constant skip count, `SIMPLE` and `WTYPE` are not needed at all.

### Related, separate: `R` is not always the number of replicates

Worth flagging while you're in this code, since it also makes `.progressr_steps` wrong.

The development version adds an exhaustive multinomial bootstrap: because there are only
`n^n` distinct multinomial resamples of `n` units, when `R` reaches that many `fwb()` uses
each exactly once and **reduces `R`** to that number. The transpiler takes `steps` from the
`R` in the call, so the bar stalls partway.

Only reachable for very small `n` (`n = 6` already has 46656 resamples, so with the default
`R = 999` nothing above `n = 4` is affected), and `fwb()` emits a message saying it has done
this. There may be nothing worth doing about it since the number of replicates isn't knowable
from the call alone, so a transpiler arguably cannot get this right in general. Recording it
rather than proposing a fix. Sorry to add this complication.

(Note: I used Claude Code to help with these edits and this issue.)

Inspectez le code généré dans template_fwb_outer et template_fwb_FUN, en commençant par la manière dont .progressr_skip_count est défini et décrémenté autour des appels à la statistique de fwb(). Vérifiez les mises à jour de la progression par rapport à la version de développement et à fwb 0.6.0, y compris le comportement dépendant de la version ; le travail est terminé lorsque la première réplication n’est pas ignorée et que les versions prises en charge produisent exactement R mises à jour lorsque le nombre de réplications est connu.

Rédigé par le modèle d'indexation à partir du texte de l'issue.