`rez release` overwrites existing releases, sometimes

With 2.60.1 (with a backport of the change in #903)

I was confused the other day why one of our baked `.rxt` files picked up some incompatible changes made I had just made (and the released files didn't match the tagged version in git)

..I might just be confusing myself further, but I think the problem is that the `rez release` checks, sometimes, don't catch that the version already exists, and then happily overwrites the existing package.

For example, the `proc` package has some unreleased changes since 0.4.0:

```
PS C:\Users\dbr\code\proc> git log
commit bd012821f6d5a6d02880bd91588158b41e5784b0 (HEAD -> master, origin/master)
Date: Thu Jul 30 09:28:41 2020 +0930

Use Shotgun username override

commit 337b9fe99019fa4a880198900ab57546009a8c60 (tag: proc-0.4.0)
Date: Wed Jul 29 16:18:02 2020 +0930

Bump

commit 0fb4724d6a9ac3f645730fc525827a5355b113b2
Date: Wed Jul 29 16:17:18 2020 +0930

Build now installs template

[...]
```

I then run `rez release`, forgetting to bump the version - this should error as 0.4.0 has already been released:
```
PS C:\Users\dbr\code\proc> rez release

================================================================================
Releasing proc-0.4.0...
================================================================================
Checking state of repository...
Resolving build environment: [...]
Invoking bez build system...
executing rezbuild.py...
[...]
\\fileserve\rez\packages\proc\0.4.0\templates

================================================================================
Release Summary
================================================================================

1 of 1 releases were successful
```

However when I later make the same mistake, it does correctly error:
```
PS C:\Users\dbr\code\proc> git log
commit bd012821f6d5a6d02880bd91588158b41e5784b0 (HEAD -> master, origin/master)
Date: Thu Jul 30 09:28:41 2020 +0930

Use Shotgun username override

commit 337b9fe99019fa4a880198900ab57546009a8c60 (tag: proc-0.4.0)
Date: Wed Jul 29 16:18:02 2020 +0930

Bump

commit 0fb4724d6a9ac3f645730fc525827a5355b113b2
Date: Wed Jul 29 16:17:18 2020 +0930

Build now installs template

[...]
PS C:\Users\dbr\code\proc> rez release

================================================================================
Releasing proc-0.4.0...
================================================================================
Checking state of repository...
15:14:44 WARNING Skipping 1/1: destination variant already exists ('\\\\fileserve\\rez\\packages\\proc\\0.4.0\\package.py[]')

================================================================================
Release Summary
================================================================================

0 of 1 releases were successful
```

I'm not too sure why the "variant already exists" error didn't pick up in the first case, and suspect this may be hard to debug (some combination of Windows weirdness and file-server-weirdness?). Even stranger is isn't picking up the tag already existing which I assume should involve less moving parts

Any ideas on why this might be happening, or other info I can provide?

Start by reproducing the two `rez release` runs for `proc-0.4.0`, comparing the existing destination variant and the `proc-0.4.0` Git tag. Trace the checks reached by `rez release` and the build entry point `rezbuild.py`. Done means an already released version is consistently rejected and cannot overwrite existing files.

Written by the indexing model from the issue text.