Test Action never covers the action's default version

#390 pointed `ci-action.yml` at the newest existing release, so the job stopped
failing on every version bump. One gap is left; a second was written up here and
is not one.

## The default is never exercised

The workflow always passes `version:`, so `VERSION="${INPUT_VERSION:-$DEFAULT_VERSION}"`
— the path every real caller of the action takes — is never run by CI.
Replacing it with a plain `$INPUT_VERSION` would keep every check green and
break everyone using `akiomik/mado@vx.y.z`.

Running the action a second time with no input would cover it, but only by going
red in the window this was fixing: between a version bump merging and the tag
being pushed, the release the default names does not exist. What does work is
preparing the install the action would find for `DEFAULT_VERSION` and running
the script with no input, then checking which version it resolved — no download,
and it fails when the fallback goes. That needs to know where the action
installs, so it belongs with #393 rather than ahead of it.

## Not a defect: a release exists before its assets do

This issue used to claim that `gh release view` can name a release CD has
created but not finished uploading to, and that a run landing in that window
404s. It cannot. Written down because #410 built the defence before checking,
and the defence is worse than the thing it defends against.

CD publishes through `houseabsolute/actions-rust-release/publish`, whose
`create-release.py` issues a single `gh release create … `, and
`gh` given assets does not create the release and then upload to it:

> When using the `create` command to attach assets to a release, separate API
> calls are made to create the release as a draft, upload the assets, and then
> publish the release.
> — `gh release create --help`

`create-release.py` says the same in `build_command`, calling it "the sequence
GitHub documents for repos that have immutable releases turned on". A published
release therefore never lacks the assets it was created with, and while the
upload runs the release is a draft, which `gh release view` does not return.

What #410 wrote instead — walking `gh release list` and taking the first release
publishing this runner's archive and its `.sha256` — cost an API call per
release walked, a hard failure on a runner that is not Linux, a second copy of
the asset-name mapping `action/entrypoint.sh` owns, and `gh release view`'s "the
release GitHub marks Latest" traded for `gh release list`'s
newest-by-creation-date, under which a patch to an older series published after
a newer one becomes what the action is tested against. It also matched asset
*names*, which appear as soon as an upload starts (`--json assets --jq '.assets[]
| {name, state}'` shows a `state` on each), so in the one case that could reach
it — a release created by hand with files dragged in afterwards — it would have
said yes while the archive was still in flight.

## Also

`cargo test` does not pass `--locked` in CI or in `just test`, so a stale
`Cargo.lock` surfaces in CD's matrix rather than on the pull request.
`scripts/release/check-versions.sh` compares the lockfile's `mado` version
against `Cargo.toml`, which catches a forgotten bump but not a lockfile that is
stale for some other reason.

Done in #410.

## Note

These were all written inside #390 and removed when it was trimmed back to the
gate it was about. See the note in #393 for what went wrong there and what to do
differently.