go/cmd/dolt: Add GOMEMLIMIT awareness via automemlimit and server config

[stebbins]

Dolt has no GOMEMLIMIT or GOGC awareness. For containerized deployments, this means the Go runtime doesn't know about cgroup memory limits, leading to OOM kills when RSS grows past the container limit.

This adds three-tier memory limit configuration:

1. DOLT_GOMEMLIMIT env var — explicit, human-readable values like "1GiB"
2. automemlimit cgroup auto-detection — sets GOMEMLIMIT to 90% of the cgroup limit
3. Silent fallthrough on bare metal when neither applies

Also adds max_go_memory to the YAML server config, applied at sql-server startup via debug.SetMemoryLimit(), and MaxGoMemory() int64 to the ServerConfig interface.

Files changed:

• go/cmd/dolt/memlimit.go (new) — configureMemoryLimit() with the three-tier logic
• go/cmd/dolt/dolt.go — calls configureMemoryLimit() early in runMain()
• go/cmd/dolt/commands/sqlserver/server.go — applies max_go_memory at sql-server startup
• go/libraries/doltcore/servercfg/ — MaxGoMemory() int64 on interface and implementations

[reltuk]

In general I'm not opposed to automatically calling SetMemoryLimit with cgroup-or-other derived values. I'm not 100% sure this needs to settable through config.yaml. I'm also not sure about the DOLT_GOMEMLIMIT, versus just relying on the already-existing mechanism of GOMEMLIMIT.

What are the tradeoffs for these two cases in your opinion?

Is the idea behind the non-standard env variable that someone wanting CLI limits on Dolt but not on random other processes which happened to have been written in Go would export DOLT_GOMEMLIMIT instead?

In general I would prefer to not add functionality to Dolt itself that seems more appropriately delegated to the operating context in which Dolt is running (cgroups, supervisor service definitions, kubernetes manifests, etc.)

[stebbins]

#10815 (comment)

closing in favor of #10820

[stebbins]

#10821

to make it easier since there are already a few PRs, i created an issue to track the concept