Support and document rootless Docker

[Lutherwaves]

Why

openblox's caller needs access to the Docker daemon. With a conventional root daemon, that access is root-equivalent on the host.

Running the daemon rootless changes the consequence of a compromise: an attacker who reaches the socket gets the unprivileged user that owns the daemon, not the host. For a tool whose entire purpose is containing untrusted code, that is a meaningful reduction in blast radius, and it needs no change to the calling application.

This composes with the openbloxd broker rather than competing with it — the broker narrows what the API can express, rootless narrows what a compromise is worth. Neither alone is as good as the pair.

What needs checking before we recommend it

This should be validated, not assumed. Specifically:

• Do the resource caps still bite? Rootless Docker has more limited cgroup access. openblox depends on PidsLimit, memory and CPU caps for containment, so if any of them silently become advisory, rootless would trade one weakness for a worse one. This is the question that decides whether we recommend it at all.
• Does runsc register and run under a rootless daemon, and is any extra configuration required?
• Does the tmpfs scratch mount behave the same, given it is sized from the memory budget?
• Does the preview relay still work? It runs over the exec channel rather than the network, so it should be unaffected — worth confirming.

Acceptance

• the above verified on a real rootless setup, with whatever does not work stated plainly
• a short section in the docs covering setup and any caveats
• if a limitation is found that weakens containment, it is documented as a warning, not omitted

Depends on #5 — the resource-limit tests are the mechanism for answering the first question rather than guessing at it.