Thanks, @takaokouji, for making me take a closer look at the caching
behavior in this workflow. Subtle and dangerous!
In the previous version, the `build/` directory was cached with this
key:
```yaml
key: ${{ runner.os }}-build-${{ hashFiles('package-lock.json') }}
```
As @takaokouji observed, this means that if a commit or PR doesn't
change `package-lock.json`, the cache key will not change. Two unrelated
builds, possibly with very different content in `src/` or elsewhere,
could share the same build cache. In this case, when the later testing
steps restore the cache, they'll both be testing the same build output.
One of them won't be testing what you expect!
Luckily, the deploy steps also used the same cache keys, so they also
didn't deploy what you expect. I say "luckily" because the alternative
is to release something that didn't run any tests.
All the caching and retrieval steps also took a lot of time, enabled
only a tiny amount of extra parallelism (in the deploy steps), and added
a lot of complexity to the workflow. Removing all of that means a
faster, easier-to-understand workflow with no sneaky gremlins making us
test or deploy the wrong thing.
