fix(bench): address the dummy remote as a file:// URL

[BryanFRD]

Follow-up to #178, which fixed a real bug but not the one that mattered. semantic-release still contributes zero cells: I checked the artifact from the run after #178 shipped rather than trusting the green tick, and it is still absent.

#178 fixed the dangling remote HEAD (fatal: couldn't find remote ref HEAD). That was real — semantic-release now gets past its git fetch and hyperfine measures it on the floor fixture (1.352 s ± 0.024 s, 30 runs). But floor cells are stripped from benchmarks by design, and the one fixture that matters still SKIPs:

[semantic-release] › ℹ  Found git tag v0.1.0 associated with version 0.1.0 on branch main
[semantic-release] › ℹ  Found 100 commits since last release
[semantic-release] › ✘  Failed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[semantic-release] › ✘  An error occurred while running semantic-release: TypeError: Invalid URL

It analyses the commits fine, then dies generating notes. semantic-release derives repositoryUrl from origin and hands it to new URL(). Our origin is the bare path mktemp -d returned:

$ node -e "new URL('/tmp/tmp.abc123')"        -> TypeError: Invalid URL
$ node -e "new URL('file:///tmp/tmp.abc123')" -> ok, protocol file:
$ node -e "new URL('C:/Users/bryan/x')"       -> ok, protocol c:

That last line is why #178 looked right. My local verification passed because a Windows path parses as a URL — C: reads as a scheme. The release notes it produced were full of https://C/Users/bryan/... links and I did not stop to ask why. On Linux the same code throws. floor masks it further: one commit, nothing releasable, so semantic-release exits before generateNotes ever runs.

Addressing the remote as file:// fixes it — a valid URL, and git clones and fetches from it identically. Verified end to end: generateNotes now completes, and semantic-release resolves "the next release version is 0.2.0".

Tests, because this bug has now outlived two fixes. setup_dummy_remote is sourced out of run.sh and pinned on: origin is a file:// URL, new URL() accepts it, the remote's HEAD matches the pushed branch, git fetch works, refs and tags land, a detached HEAD fails loudly, and a re-run is not fatal. The bare-path regression is verified to make test 1 fail.

One caveat worth stating: the new URL() test only bites on POSIX — on Windows it goes green even with the bare path, the same trap as above. The file:// prefix assertion is the portable guard; that test is documentation of why. It is commented as such.