infra: image needs --ulimit memlock=-1 by default (pinned buffer pools exceed container default 8 MiB) #59

Problem

The device-emulator image's runtime memlock budget (default container value ulimit -l = 8192 KB on most hosts) is too small for the pinned buffer pools used by the proxy server and its zero-copy data path. This becomes a hard failure on any code path that allocates a non-trivial bucketed buffer; for example, the #55 4 MiB bandwidth probe throws:

exception caught in Thread proxy_listener0
reason: AlignedBufferPool: pin_fn_ failed

from csrc/backend/serialization_buffer.h:106.

The fix on the operator side is docker run --ulimit memlock=-1 ..., and this is now documented in docs/deployment.md under "Quick start with --measurement" (commit 7077777). But:

1. The other Quick-start examples earlier in deployment.md don't include the flag.
2. Nothing in the Dockerfile or make docker-build / make docker-test Makefile targets sets it.
3. There's no runtime check that fails early with a friendlier error.

Suggested fix (one of, or any combination)

A — Update all documented docker run invocations in docs/deployment.md, docs/DOCKER.md, and docs/DEV_README.md to consistently include --ulimit memlock=-1.

B — Update Makefile targets (docker-test, docker-run, etc.) to pass --ulimit memlock=-1 so users using make don't hit this even once.

C — Add a runtime preflight check in ProxyEnvCfg::Initialize (or wherever the buffer pools are first allocated) that calls getrlimit(RLIMIT_MEMLOCK) and logs a LOG_WARN if it's below some sensible threshold (e.g. bandwidth_payload_bytes * 4), pointing at the deployment docs. Pure ergonomics — doesn't change behavior, just turns a cryptic pin_fn_ failed into a directed warning.

Why this matters

The current behavior (silent failure on the server listener thread mid-flight, no front-line error message) is exactly the kind of thing that costs a new contributor a half-day. Surfaced during #55 step 8; not a #55 bug but worth fixing once.