Updates fail with `line 17: sions: command not found` on the next update after updating to v4.7.45

Describe the bug
Under certain circumstances when updating a CLI using this plugin, the update will succeed but will exit with an error that looks like this:

$ mc update
mc: Updating CLI from 1.0.0-abcdefgh to 2.0.0-hgfedcba... done
/Users/user/.local/share/mc/client/bin/mc: line 17: sions: command not found
$ echo $?
127

This unexpectedly breaks some usage like mc update && mc <command> where the update did succeed but then the subsequent command doesn't get run since the update exited with a non-zero exit code.

(The actual CLI name/version is renamed for illustration purposes.)

In particular it happens when the CLI was using plugin-update v4.7.44 or earlier and had run an update with that earlier plugin version, then updating to a CLI version that is using plugin-update v4.7.45 or later, then running an update.

To Reproduce
Steps to reproduce the behavior:

1. Install a CLI version using plugin-update 4.47.44 or earlier
2. Run cli update to some version using plugin-update 4.47.45 or later
3. Run cli update again to some other version (any version as long as it's not the current version as installed in step 2; a locally cached version or even the version in step 1 will work)

Expected behavior
Exits without the error output, and with exit code 0.

Environment:

• OS & version: macOS 26.6.2
• Shell/terminal & version: zsh 5.9 (arm64-apple-darwin25.0), bash GNU bash, version 3.2.57(1)-release (arm64-apple-darwin25)

Additional context
In my setup this CLI is on the PATH at ~/.local/bin/mc which symlinks to ~/.local/lib/mc/bin/mc. I believe that script then redirects to and runs ~/.local/share/mc/client/bin/mc.

There was a change in v4.7.45 is #1338 which seems to be trying to solve a related problem. However I think it causes this specific issue, because the script was 16 lines long and is maybe unchanged since 9b3e33b398bb1926583d9f4f2aca1fddeeafd242, but after #1338 the script is longer and has more lines, so when updating with the v4.47.45+ updater, after the CLI exits bash resumes from where it left off in the byte offset in ~/.local/share/mc/client/bin/mc after the final newline in the file, but because of the changed length of the file it now thinks that there's a line 17 of sions\n (tail end of the new comment that was added before the block) followed by more lines

# Ensure everything is read at once before execution to avoid race conditions when updating versions
{
  DIR=$(get_script_dir)
  MC_BINPATH="$DIR/mc" MC_REDIRECTED=1 "$DIR/../2.0.0-hgfedcba/bin/mc" "$@"
}; exit

Maybe that bash fix works for future changes to the script, but can we consider fixing the updater so that it does not affect any bash shell that currently has the file ~/.local/share/mc/client/bin/mc open. For example instead of overwriting the existing file, write a new file and then rename over the old file, so that when the CLI exits and bash resumes execution in the shim, it will still always be on the old file/inode.

Looking at the history around writing this file, it seems that before #643 it was a sequence of remove and then write new file, and after #643 it turned into a overwrite of the existing file.

Looking at the contents of the file, apart from overall layout/structure changes as in #1338, increase in the length of version would also trigger this, which I guess is what #1338 was trying to fix.

I have not tested if there is an similar issue on Windows with the .cmd files, but if the shell there does something similar (read until byte offset and resume later) then there might be issues too.

Start with the updater logic that writes ~/.local/share/mc/client/bin/mc, then review the history around #643 and #1338. Reproduce the three-version update sequence on macOS and inspect how the running shell reads the shim during replacement. Done means a subsequent update exits with code 0 and produces no command-not-found error, including when the shim changes length.