Run the GNSS simulator in production too

Adds a gnss-simulator service to docker-compose.yaml, sharing
maptool's network namespace (network_mode: "service:maptool") so it's
reachable at the 127.0.0.1:2947 GpsdClient hardcodes -- there's no
real receiver attached to the server, so without this the "GNSS"
control there always shows "no fix". Both services now reference the
same image (maptool:latest) explicitly rather than each service with
its own `build: .` producing two separately-tagged (if
identically-layered) images.

Verified for real: built and ran the full compose stack in an
isolated project/port on cube (not the live one), confirmed
/api/gnss/position reports a moving fix across two polls through the
actual sidecar networking, then tore it down completely -- containers,
image, network, temp checkout. Production's own stack was untouched
throughout and confirmed still healthy afterward.

docker-compose.yaml

@@ -1,6 +1,7 @@
 services:
   maptool:
     build: .
+    image: maptool:latest
     restart: unless-stopped
     ports:
       - "4567:4567"
@@ -26,3 +27,19 @@ services:
       # docs/development.adoc for how the deploy job treats this
       # directory).
       - ./data:/app/data
+
+  # Fakes a GNSS fix (a loop around Bratislava, see
+  # bin/gnss_simulator.rb/docs/development.adoc) since there's no real
+  # receiver attached here — the "GNSS" control would otherwise just show
+  # "no fix" always. Remove this service (and nothing else) whenever a real
+  # receiver/gpsd setup replaces it. network_mode ties it to maptool's own
+  # network namespace rather than a bridge network, since GpsdClient
+  # connects to a hardcoded 127.0.0.1:2947 — same as gpsd itself normally
+  # being local to the machine it serves.
+  gnss-simulator:
+    image: maptool:latest
+    depends_on:
+      - maptool
+    restart: unless-stopped
+    network_mode: "service:maptool"
+    command: ["ruby", "bin/gnss_simulator.rb"]