chore: upgrade forge deps and fix builds on darwin

[alanshaw]

Upgrades Forge deps and enables CGO on Darwin due to gosigar requiring it on macos. Also fixes the binary builds on release.

Why does `gosigar` require CGO on Darwin?

On macOS the system stats gosigar reports only exist behind C library
interfaces, and the file that wraps them is a cgo file.

In gosigar (github.com/elastic/gosigar) the darwin implementation is split
in two:

• sigar_common_darwin.go starts with a C preamble (#include <sys/sysctl.h>, <mach/mach_host.h>, <libproc.h>, …) and import "C".
  It implements Cpu.Get, Mem.Get, Swap.Get, LoadAverage.Get, process
  info, and the sysctlbyname helper by calling getloadavg,
  host_statistics, host_processor_info, proc_pidinfo, and
  sysctlbyname directly.
• sigar_darwin.go and concrete_sigar.go are pure Go and call into those.

When CGO_ENABLED=0, the Go toolchain silently drops every file that imports
"C" from the package. sigar_common_darwin.go vanishes, and the surviving
pure-Go files fail to compile against the now-missing pieces. That is the
error signature piri's make test produced on macOS:

sigar_darwin.go:13:12: undefined: sysctlbyname
concrete_sigar.go:20:12: cpuUsage.Get undefined (type Cpu has no field or method Get)

The reason darwin uses C where Linux doesn't: on Linux all of this data is
plain text under /proc and /sys, so sigar_linux.go just reads files.
macOS has no /proc; CPU, memory, and process stats come from Mach kernel
APIs (host_statistics, host_processor_info) and libproc, and Apple's
only stable way to reach those is through the system C library. There is no
pure-Go path for the Mach calls (raw syscall numbers are not a supported
interface on macOS), so cgo is unavoidable. gosigar is also a direct port of
the old C libsigar (the VMware copyright header is still on the file), which
is why the darwin port stayed a thin C wrapper rather than using the partial
pure-Go sysctl support in golang.org/x/sys/unix.

Note: The build passes in CI on MacOS due to a bug in the unified-github-workflows CI config that ended up enabling CGO for all builds. It's fixed in ipdxco/unified-github-workflows#148, but when merged and released we'll have to fix our CI config here as we won't be able to use "cgo": false config since on MacOS it is required to be true.

[Copilot]

Pull request overview

Upgrades Fil-Forge/Forge-related dependencies and adjusts the local build/test workflow so macOS (Darwin) builds can enable CGO (to support gosigar requirements in the Curio/Lotus dependency chain) while keeping non-Darwin builds CGO-free by default.

Changes:

• Update Makefile to set CGO_ENABLED based on the host OS and use it for go build / go test.
• Bump Forge-related module versions in go.mod.
• Refresh corresponding checksums in go.sum.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.

File	Description
Makefile	Conditionally enables CGO on Darwin and propagates CGO_ENABLED into build/test commands.
go.mod	Updates Forge/Fil-Forge dependency versions.
go.sum	Updates module checksums to match the upgraded dependencies.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Makefile:16

• The comment about overriding CGO is misleading on Darwin: this Makefile already defaults CGO_ENABLED to 1 on Darwin, so the guidance about overriding with CGO_ENABLED=1 only applies to non-Darwin. Consider rewording to describe the actual defaults and note that Darwin cross-compiles may need CGO_ENABLED=0.

# gosigar (via curio→lotus) has a pure-Go path on linux but needs cgo on darwin.
# Default to CGO-free builds on non-darwin platforms; override with CGO_ENABLED=1 if needed.