Add a manifest field to set an app container's /dev/shm size, in the same shape as the existing
memoryLimit.

What we hit

Our community package for vLLM updated from upstream 0.26.0
to 0.27.1. The new version runs its inference engine in a separate process and brokers work between
the two over a POSIX shared-memory ring buffer. It refuses to start if /dev/shm is too small:

RuntimeError: Insufficient space in /dev/shm: 160 MiB required, 62 MiB free.
Increase /dev/shm (e.g. --shm-size or --ipc=host).

A Cloudron app container gets a fixed 64 MiB, confirmed on two independent installs on two
different Cloudron servers (9.x and 8.3.x):

$ df -h /dev/shm
shm              64M   76K   64M   1% /dev/shm

We could find no way to change it: no manifest field, no CLI flag, and nothing in the app
configuration UI.

Why we think it is worth a platform change rather than a per-app workaround

The 64 MiB default is Docker's, and it predates the current generation of workloads. Anything using
PyTorch or Python multiprocessing shared memory, headless Chrome or Chromium (a very common
packaging target), or a database tuned with large shared buffers, runs into the same ceiling. In
every case the symptom is a confusing message from a library several layers down rather than
"your platform gives you 64 MiB", so the diagnosis is expensive each time. It cost us about
twenty minutes on a package we already understood well.

It is also the kind of limit that only bites on update. Our 0.26.0 install is healthy today. Had
we published 0.27.1 without catching this, every install would have updated into a container that
cannot boot at all — and because the app never becomes healthy, the failure presents as an install
problem rather than a resource one.

What we did instead, in case it is useful to others

vLLM can run its engine in-process, which never allocates the ring buffer. On a single-model,
single-replica CPU server that costs nothing, so our start.sh now measures the free space in
/dev/shm at boot and sets VLLM_ENABLE_V1_MULTIPROCESSING=0 when it is under 200 MiB, logging the
reason. It is written as a detection rather than a constant so the package returns to upstream's
default automatically if the platform limit ever rises.

That works, and we are shipping it. But it is a workaround chosen because the platform value is
fixed, and the next package to hit this may not have an equivalent escape hatch.

Suggested shape

{
  "memoryLimit": 10737418240,
  "shmSize": 268435456
}

Defaulting to today's 64 MiB, capped at some fraction of memoryLimit so it cannot be used to
evade memory accounting, and ignored by older boxes so manifests stay backward compatible.

Happy to test a build.