Adjust overcommit and max_map_count vm defaults in guest VMs

[adityabagchi24]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

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) legitimately exceed.

Fixes #2053

Motivation and Context

These stock defaults cause common oversubscribed-mmap and many-mapping workloads to fail inside a container even though they work on a typical host. This PR applies container-friendly defaults at container start so these workloads succeed, while actual memory usage remains enforced by the container's existing --memory limit (via cgroup memory limit and the OOM killer).

Implementation

• Sources/Services/RuntimeLinux/Server/RuntimeService.swift: set vm.overcommit_memory=1 and vm.max_map_count=262144 as defaults when configuring a container's guest sysctls.

[github-actions]

Code Coverage

Tier	Line Coverage
Unit	24.33%
Integration	66.2%
Combined	75.59%