F1 (rework): source guest RAM cap from docker info; deploy guard uses committed memory

The cgroup-only approach was a no-op on the demo: the controller container's OWN
cgroup is unlimited (the 2GB cap is on the LXC ancestor, hidden), and /proc has no
lxcfs, so it kept reporting the host's 16GB. The Docker daemon runs IN the LXC, so
'docker info' MemTotal reports the guest's real cap (2048MB) — now the authoritative
source (cgroup limit preferred when present, e.g. non-nested). The deploy memory
guard now uses the controller's committed-app memory (sum of running mem requests)
for 'used' — accurate and cheap — instead of host /proc RSS (unobservable per guest;
would make the guard never/always fire). /api/system/info reports the guest cap as
total and committed memory as used. Tests: cgroup-limit path, docker-info fallback
(nested case), GuestMemTotalMB fallback (dockerMemTotalFn stub).

controller/internal/system/info_other.go

@@ -18,3 +18,8 @@ func GetTotalMemoryMB() (int, error) {
 func GetMemoryMB() (totalMB, usedMB int, err error) {
 	return 0, 0, fmt.Errorf("/proc/meminfo not available on this platform")
 }
+
+// GuestMemTotalMB is not determinable on non-Linux platforms.
+func GuestMemTotalMB() (int, bool) {
+	return 0, false
+}