Force-pushed branch not picked up by multi-revision repo (returns "Already-up-to-date")

## Bug report ### Expected behavior and actual behavior When the upstream branch is force-pushed (history rewritten), Nextflow's multi-revision repository strategy does **not** detect the change. The bare repo silently keeps the old SHA and `download()` short-circuits with `Already-up-to-date`, so the pipeline continues to run the stale commit. ### Steps to reproduce 1. Run a pipeline pointing at a remote branch (e.g. `main`) so Nextflow caches it under `~/.nextflow/assets/.repos/<project>/bare/`. 2. On the remote, rewrite history of that branch and push with `--force`. 3. Run Nextflow again with the same revision. Observed: local `refs/heads/<branch>` in the bare repo still points at the old commit; the corresponding `clones/<oldSha>/` still exists; `download()` returns `Already-up-to-date`. ### Root cause `MultiRevisionRepositoryStrategy.refSpecForName(...)` constructs `RefSpec`s without the leading `+` that allows non-fast-forward updates. After a force-push, JGit's `FetchCommand` records `REJECTED` for the local ref update (visible via `FetchResult.getTrackingRefUpdates()`) but does **not** throw, so the bare repo silently keeps the old SHA. Then `revisionToCommitWithBareRepo()` resolves to the stale commit, whose clone directory still exists, and `download()` short-circuits. ### Verified Confirmed on a real reproduction with diagnostic logging: ``` DEBUG n.s.MultiRevisionRepositoryStrategy - Bare repo fetch update for jorgee/nf-sleep [revision: main]: refs/heads/main <- refs/heads/main => REJECTED (old=3851da8d..., new=d17b807d...) ``` JGit fetched the new object but refused to move the local branch ref because the update was non-fast-forward. ### Affected file `modules/nextflow/src/main/groovy/nextflow/scm/MultiRevisionRepositoryStrategy.groovy`