Increase Podman resources

Makefile

@@ -18,9 +18,29 @@ STATE_DIR    := $(HOME)/.local/state/opencode
 # inotify file-change events don't propagate into the container. Not a
 # blocker for this sandbox, just a rough edge if a tool relies on watching
 # /workspace for live changes.
+#
+# --memory/--memory-swap/--cpus: on macOS, `podman machine`'s Linux VM has a
+# FIXED resource allocation (check with `podman machine inspect`; currently
+# 4 GiB / 6 CPUs, bumped up from the 2 GiB default -- see `podman machine
+# set --memory <MB> podman-machine-default`, which requires the machine to
+# be stopped first). Without a cgroup cap here, a memory-hungry build tool
+# (Gradle's daemon and its separate Kotlin-compiler daemon are the worst
+# offenders -- both size their heap off "available" memory with no idea
+# they're sharing a small VM) can consume the VM's *entire* RAM. That
+# doesn't just OOM-kill the container -- it starves the VM's own guest
+# kernel, which stalls the very processes Podman needs to stay responsive
+# (its API socket, gvproxy, SSH), making the whole machine appear to hang.
+# Capping the container forces a contained OOM kill instead. --memory-swap
+# equal to --memory disables extra swap for the container specifically, so
+# it fails fast rather than thrashing. Sized to leave ~1 GiB / 2 CPUs of
+# headroom below the VM's own allocation for the VM/podman/gvproxy itself --
+# adjust alongside `podman machine set` if you resize the machine again.
 RUN_FLAGS := \
 	--rm -it \
 	--userns=keep-id \
+	--memory=3072m \
+	--memory-swap=3072m \
+	--cpus=4 \
 	--network $(NETWORK_NAME) \
 	--network-alias $(WORKDIR_NAME) \
 	-v $(CURDIR):/workspace \