docs(releases): note toolchain caches working in the sandbox

docs/releases/v0.2.0.md

@@ -67,6 +67,7 @@ Run `flynn version` afterwards; it should name a `v0.2.0-rc` release. v0.1.3 can
 - A local model runtime installed by v0.1.3 stopped working after the upgrade: v0.1.3 wrote no hash record beside it, so it was refused as corrupt. Flynn now treats it as unverified and fetches it again through the verified install, and `flynn models check` reports it as needing a reinstall instead of CORRUPT. A runtime whose hash record disagrees with the binary is still refused.
 - Stored timestamps sort in time order.
 - Two Flynn processes opening the same new database at once (a goal starting while you run `flynn runs`, or two commands after an upgrade that adds migrations) could fail with `no such column: "uses"`, because both applied every migration. Each migration is now applied under the database write lock after checking it was not already applied, and the first connection waits out a competing one.
+- `go test`, `npm install` and `pip install` failed inside the sandbox: a confined command could not write the caches these tools keep under the home directory, on macOS it could not write its own `TMPDIR`, and on Windows its `TEMP` was the workspace, where Go ignores a `go.mod`. Each sandbox now has a private scratch directory outside the workspace, writable by its commands and deleted when the sandbox closes. The temp variables, `GOCACHE`, `GOMODCACHE`, `npm_config_cache` and `PIP_CACHE_DIR` point into it unless you set them yourself. On Linux it is under `/var/tmp`, so the caches last from one command to the next.
 - A confined signer on Windows can read its sealed key.
 - The interactive session could hang reading input when a multi-byte character arrived with no room left for it in the read buffer.
 - Markdown in the terminal could render a line one cell wider than the screen, so it wrapped.