docker: publishable runtime image (ghcr.io/orlyatomics/orly) with in-container orlyc (#530)

[ohohoreilly]

Closes #530. The last mile of "try Orly in five minutes" for the agent-shared-memory direction (#526/#528) — and the only way to run Orly on non-Linux hosts (the engine is hard-Linux-only: epoll, libaio, eventfd).

What

• Dockerfile (multi-stage):
  • build: Ubuntu 24.04 build deps, make bootstrap + jhm -c release for just orlyi and orlyc, then the built orlyc pre-compiles the example packages (sample, graph, market) — each orlyc run stands up and tears down its embedded server, so the binaries get smoked during the image build itself;
  • runtime: the ldd-verified .so set, plus g++, uuid-dev, and the source tree (ORLY_SRC_ROOT=/opt/orly/src/) so user .orly packages compile inside the container — docker exec <ctr> orlyc -o ... yourpkg.orly yields a loadable .so.
• docker/entrypoint.sh: solo mem-sim orlyi, WS on 8082, baked package dir, conservative sizing via env (ORLY_MEM_SIM_MB, ...); extra docker run args pass through verbatim, so any orlyi flag can be overridden.
• .github/workflows/docker.yml: PRs touching the docker files build the image and gate it twice — the clients/mcp smoke pointed at the containerized server (full tool surface against the published artifact), and an in-container from-scratch package compile. workflow_dispatch or a v* tag additionally pushes ghcr.io/orlyatomics/orly (:latest + the version tag).
• README: a Docker quick start ahead of the from-source path.
• .dockerignore: notably excludes the host-built tools/jhm/tools/make_dep_file — if those leak into the context, make bootstrap skips bootstrap.sh and the .jhm tree-root marker it creates, and the build dies at jhm's "Unable to find .jhm".

Verified locally (716MB image)

• MCP smoke against the running container: all nine assertions green (tools list, install of the baked sample.1, pov, write/read, atomic 3-write batch, error surface).
• In-container orlyc compile of a new package to a loadable .so (this check caught a missing uuid-dev — generated code includes base/uuid.h → <uuid/uuid.h>, so the runtime lib alone is not enough; the gate now covers it in CI).
• mlock needs no ulimit ceremony: failure already degrades silently (ENOMEM/EPERM path in base/mlock.cc).

Out of scope

Disk-mode persistence docs beyond the flag pass-through, multi-arch (amd64 only), Docker Hub mirroring. First publish to ghcr is a workflow_dispatch away once this merges.