fix: resolve Sage caches from HOME in container jobs

[marcopellegrinoit]

Summary

• Hash go.sum from the workspace shell instead of hashFiles('**/go.sum'), which looks under /home/runner/work and fails when the job runs in a container.
• Point KOCACHE and the actions/cache paths at ~ / $HOME, so they follow /home/runner on a hosted runner and /github/home inside a container.

Testing

• Run a job with container: and confirm setup no longer fails on hashFiles, and that the post-job cache save writes under $HOME.
• Re-run that container job and confirm the tool caches are present before the build.

Replaces #877, which was opened from a fork.

[fredrikaverpil]

This action was originally meant to be kept simple and cover 80% of cases. But for the remaining 20% it might be necessary to set up your own action for caching. However, the more correct handling of home path seems like a nice improvement to me, so let's merge this! 🚀

On top of @marcopellegrinoit's change from #877, I've addressed the following:

• The "Hash go.sum files" step is skipped when disableCache: 'true', matching the cache step.
• go.sum paths are passed null-separated (find -print0 | sort -z | xargs -0), so paths containing spaces hash correctly. For normal paths the hash is unchanged.
• Removed the unused id: cache from the cache step.

Known/possible limitations, not addressed here:

• Images that set GOPATH: the official golang:* images set GOPATH=/go. Modules and go install binaries then go to /go/pkg/mod and /go/bin, which aren't in the cache paths. Those caches stay cold, though go-build still works. A fix would be to resolve the paths with go env GOMODCACHE / go env GOPATH instead of hardcoding ~/go/....
• Host and container jobs can share a cache key: with the default cacheKey (the workflow name), a host job and a container job in the same workflow produce the same key. As far as I know, actions/cache versions caches by the literal path strings, so ~/... matches in both. A container job could therefore restore a host-saved archive and unpack the $HOME contents in the wrong place, or get .sage/tools binaries built for a different libc. Passing a separate cacheKey per job avoids this; adding $HOME to the key would fix it.
• The container needs some basic tools: the hash step needs find, sort -z, xargs -0, sha256sum and awk, alongside the existing bash requirement and the tar that actions/cache needs. Debian/Ubuntu-based and Alpine images have these; minimal or distroless images may not.
• macOS runners: hashFiles() needed no external tools, but this step relies on sha256sum. It hasn't been checked on macOS runner images.