Publish stage clears its download folders so a leftover tarball cannot be read

[mcollinscodat]

Summary

The Azure DevOps pipeline that publishes this repo's npm packages reads the packed tarball out of a folder it never empties, so a run that lands on an agent which has already served an earlier release finds that release's tarball still on disk and picks up both filenames as one. Platform 7.0.0 failed to publish on 27 August this way: lending's tarball from a run that had finished moments earlier was still there, tar was handed both names as a single filename, and nothing reached npm. A straight re-run hit the same wall against a different leftover, so the release stayed stuck.

Changes

• A new first step in the publish job removes the two folders the artifact downloads write into, so nothing an earlier run left behind can be read.
• The step that reads the package name and version out of the tarball now fails with a directory listing unless the folder holds exactly one, rather than building a filename out of two names.
• The publish step names that one tarball instead of globbing, so a stray file can never be handed to npm.

This file is generated, so the change was made at its source and delivered here unchanged.

Verification

The structural tests for this pipeline pass at the source, and the new guard was exercised in bash with zero, one and two tarballs in the folder. All tests passing.