The registry's public name is a second module beside the store, locked by the registry itself

The predecessor serves the registry under a public name, behind htpasswd basic auth, with a
twenty-gigabyte body limit for layer pushes. The mesh's registry has no name, no lock and no
limit — by design inside the mesh, where the private network is the boundary and every node
pulls without an account (hq ADR 0082). Taking the name over must not change that.

A route on `distribution` itself would: contributing a route is requiring one, and the store
is raised at genesis on a node with no proxy. So the public door is `distribution-gate`, a
second registry process on the same volume, behind the registry's own htpasswd (the
predecessor's realm, the predecessor's file, carried in with `secret accept`), with the
route and its limit. It requires the store's storage as a node-scoped provision, so it can
only land beside the store. The store's own door is untouched — no auth, no htpasswd — which
is what keeps the builder's pushes and every node's pulls working.

Both processes read the predecessor's configuration where it changed behaviour: delete
enabled, which tag retention depends on; no per-process descriptor cache, which two
processes over one store cannot share; the CORS headers for the retired interface dropped.

route-adapter writes the limit as the predecessor's own buffering middleware, named after
the router, only when asked for — and skips a route whose limit it cannot read rather than
carrying what the module said not to.

hq ADR 0082/0104, the registry hand-over.

modules/route-adapter/README.md

@@ -56,12 +56,31 @@ http:
           - url: http://host.docker.internal:2999
 ```
 
+A contribution may also carry **`max-request-body`**, the largest request body in bytes the proxy
+may carry to it — the registry's public name needs twenty gigabytes for a layer push (novox/hq
+ADR 0082, the registry hand-over). It is written as the predecessor's own `buffering` middleware,
+named after the router, and only when asked for:
+
+```yaml
+  routers:
+    mesh-registry-api-example:
+      # …
+      middlewares: [mesh-registry-api-example-body]
+  middlewares:
+    mesh-registry-api-example-body:
+      buffering:
+        maxRequestBodyBytes: 21474836480
+```
+
 - **The certificate resolver is the predecessor's own**, by its own name. The predecessor already
   holds a certificate for every public name it serves, so naming its resolver means a migrated name
   is served from the certificate that exists. A resolver of the mesh's would ask a public authority
   for one in the same window the module is cut over — the risk ADR 0104 exists to remove.
 - **The port is the contributor's**, straight out of the contribution: the mesh assigned the
   machine-side number (novox/hq ADR 0038) and carries it there. Nothing here guesses it.
+- **A limit it cannot honour is a route it does not write.** A `max-request-body` that is not a
+  whole positive number of bytes is skipped and named, like a port that is not one — written
+  without the limit, the predecessor would carry exactly what the module said not to carry.
 - **The address is where the mesh says that machine is.** Empty means this one, reached from inside
   the predecessor's container at `host.docker.internal` — not loopback, which from inside that
   container is the container. A contributor on another node carries its overlay address and the
@@ -157,5 +176,6 @@ cd modules/route-adapter && npm test
 ```
 
 They hold it to what ADR 0104 says holds it: one file per contribution, a file removed when its
-contribution goes, every file it did not write left alone — and the two facts a route file has to
-get right, the port the contributor publishes and the address of the machine it is on.
+contribution goes, every file it did not write left alone — and the three facts a route file has to
+get right: the port the contributor publishes, the address of the machine it is on, and the body
+limit it asked for, written as the predecessor's middleware or not at all.