Adjust overcommit and max_map_count vm defaults in guest VMs (#2055)

Each container runs in its own guest VM sized to
`--memory` with no swap, so the guest kernel's
stock `vm` sysctl defaults are hit far too easily:

- `vm.overcommit_memory=0` (heuristic overcommit)
  rejects an oversized `mmap()` upfront whenever the
  reservation exceeds the small, swap-less VM's free
  RAM — even if the memory is never touched —
  returning `ENOMEM`.
- `vm.max_map_count=65530` caps per-process
  mapping count, which mapping-heavy applications
  (e.g. Elasticsearch, many JVMs) can exceed.

Sources/Services/RuntimeLinux/Server/RuntimeService.swift

@@ -1063,9 +1063,12 @@ public actor RuntimeService {
         czConfig.cpus = config.resources.cpus
         czConfig.cpuOverhead = config.resources.cpuOverhead
         czConfig.memoryInBytes = config.resources.memoryInBytes
-        czConfig.sysctl = config.sysctls.reduce(into: [String: String]()) {
-            $0[$1.key] = $1.value
-        }
+        // Overcommit memory and allow more memory mappings than the kernel default
+        // so workloads inside swap-less guest VMs hit limits less easily.
+        var sysctls = config.sysctls
+        sysctls["vm.overcommit_memory"] = "1"
+        sysctls["vm.max_map_count"] = "262144"
+        czConfig.sysctl = sysctls
         // If the host doesn't support this, we'll throw on container creation.
         czConfig.virtualization = config.virtualization
         czConfig.useInit = config.useInit