How to handle `nvm` errors?

@geriux reported an `nvm` related failure yesterday. From [this build](https://buildkite.com/automattic/gutenberg-mobile/builds/7592#018b47d2-dc5b-4f93-aa7e-353c44ac1c15):

```
Installing node.js version specified in the .nvmrc file
Found '/usr/local/var/buildkite-agent/builds/MV-MKE-X64-014/automattic/gutenberg-mobile/.nvmrc' with version <16>
Downloading and installing node v16.20.2...
Downloading https://nodejs.org/dist/v16.20.2/node-v16.20.2-darwin-x64.tar.xz...
curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
Binary download from https://nodejs.org/dist/v16.20.2/node-v16.20.2-darwin-x64.tar.xz failed, trying source.
grep: /private/var/folders/xl/csng4q450h96m4tbz0p12_xh0000gn/T/automattic-nvm-XXXXXXXX.RmpKxyu4/.cache/bin/node-v16.20.2-darwin-x64/node-v16.20.2-darwin-x64.tar.xz: No such file or directory
Provided file to checksum does not exist.
/private/var/folders/xl/csng4q450h96m4tbz0p12_xh0000gn/T/automattic-nvm-XXXXXXXX.RmpKxyu4/nvm.sh: line 2105: TMPDIR: unbound variable
```

It looks like the tar archive failed. `nvm` then tried to compile from source, but since it looks like it searches for the source in the archive, that failed, too.

How should we handle failures like this? Should we assume a failure in `nvm install` is likely HTTP-related and retry a few times?

Or, should we not worry given the relatively low occurrence of these issues and the fact that we'll soon provision the macOS machines with the versions of Node we know we need?

The report identifies Buildkite build 7592, the repository’s .nvmrc, and nvm.sh at line 2105; start by reviewing that installation log and the plugin’s nvm failure path. Compare the failed archive download and source fallback with the proposed retry and macOS pre-provisioning options. Done means an agreed failure-handling approach is implemented or the issue is explicitly closed.

Written by the indexing model from the issue text.