fix(resources): make storage-capacity observer link on non-unix targets

[antoinetoussaint-byte]

Summary

• resources/storage_capacity.go called syscall.Statfs/Statfs_t in a build-tag-free file, so resourcesfailed to compile for any GOOS without statfs (e.g. windows): undefined: syscall.Statfs_t.
• Agent releases run goreleaser release with its default GOOS matrix (linux, darwin, windows), so every service-* release build broke at this file — this is why no agent could be tagged+released on core v0.3.8 (Bump cli-owned-build agent repos to core v0.3.8 (Go 1.27 + golangci-lint CI fix) cli#452).
• Split the syscall-backed observer behind build tags: real impl → storage_capacity_unix.go (//go:build unix); a //go:build !unix stub returns a clear unsupported on <GOOS> runtime error so the package links everywhere rather than breaking the cross-compile. Portable code + InspectStorageTree stay shared.

Test plan

• GOOS=windows GOARCH=amd64 go build ./resources/ now succeeds (was the failing target)
• GOOS=linux/host go build ./... clean; go test ./resources/ green (unix path unchanged)
• new //go:build !unix test asserts the stub errors and InspectStorageTree propagates it
• gofmt clean; standard golangci-lint clean on the touched files

⚠️ Necessary but not sufficient for the fleet release

This unblocks the first cross-compile error only. core is effectively Unix-only: runners/base, code, and runners/python also fail a windows build (syscall.Kill, SysProcAttr.Setpgid, process groups). The durable fix for agent releases is to constrain the goreleaser matrix to goos: [linux, darwin] (the only platforms the codefly loader consumes) rather than guard every unix-only package for a target that is never shipped. Filed as follow-up — see PR discussion.

[antoinetoussaint-byte]

Superseded by the real fix. Root cause wasn't core portability — it was that two agent repos (service-envoy, service-neo4j) lacked the .goreleaser.yaml the rest of the fleet has, so their releases fell back to zero-config GoReleaser and tried to build Windows. Restricting those repos' release matrix to linux/darwin (service-envoy#14, service-neo4j#14) is the correct fix. Guarding only resources for non-unix is incoherent while runners/base, code, and runners/python remain Unix-only by design, so closing this rather than carry false portability.