Go GC behavior on sub-256MB RISC-V targets — tuning strategy?

[kinhluan]

PicoClaw's Go choice makes a lot of sense for developer velocity and cross-compilation (GOOS/GOARCH is incredibly convenient). But I'm curious about one fundamental tradeoff on the $9.9 LicheeRV-Nano target (SG2002, 256MB DDR3):

Go's runtime includes a concurrent garbage collector that's optimized for throughput on server-class hardware. On a 256MB RISC-V board running a long-lived agent daemon:

1. Has the team observed GC pause spikes during sustained tool-call loops? (e.g., GODEBUG=gctrace=1 output on actual LicheeRV-Nano hardware)
2. The README notes memory grew from <10MB to 10-20MB after recent PRs — is there a target ceiling the team is tracking? At what point does Go's runtime overhead become a concern on these boards?
3. Are there plans to tune GOGC / GOMEMLIMIT for embedded profiles, or is this left to the deployer?

For context, I noticed the JSONL memory store and sharded mutex design (numLockShards = 64) are clearly optimized for low overhead — but the GC itself is the one piece you can't design around in Go. Curious how the team navigates this on real Sipeed hardware.