A gate judges its own send and the build it sent, and never puts the controller back behind its store (hq issue 352)

On 2026-10-09 a release's gate on the control node read the machine's
report against a newer send another plan had just made there, failed
three builds the machine had reported healthy, and put them back on
every machine to a controller older than the store's schema; that
controller then passed the newer plan's gate from its own health.

- A gate keeps what its send carried (digest, sequence) and reads the
  report against it; a report on the last send is on it too.
- A gate judges only the build the machine was last sent: another build
  there supersedes the judging — no verdict, nothing put back.
- A controller is told its build (MESH_CONTROLLER_VERSION, ${version}
  in a process's env) and records how far it reads the store's schema;
  a put-back to a build that reaches less, or never said, is refused
  and the current build kept, said as urgent.
- A release's open gate holds other sends of its modules there, and a
  plan's own first send waits on it.

module.json

@@ -118,7 +118,8 @@
         "MESH_STORE_LICENCES_PORT": "${seat:mesh-store:5432}",
         "MESH_BROKER_MANAGEMENT_PORT": "${seat:mesh-broker:15672}",
         "MESH_BROKER_ADDRESS_PORT": "${seat:mesh-broker:5671}",
-        "MESH_BUS_NATS_FILE": "${dir:mesh-state}/bus"
+        "MESH_BUS_NATS_FILE": "${dir:mesh-state}/bus",
+        "MESH_CONTROLLER_VERSION": "${version}"
       },
       "replaces": [
         "server"