ipx-play's metrics on 9191: 9189 is hnopml's (#458)

5d0ff1a put ipx-play's /metrics on 9189, but hnopml, in the same
compose project, has published 192.168.1.130:9189 since 2026-11-12 and
Prometheus scrapes it there as job="hnopml". Deployed as written,
ipx-play's port would have clashed with it. 9187 to 9190 are ipx, the
directory, hnopml and ipx-web; 9191 is free.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/play.md

@@ -38,7 +38,7 @@ The compose service, beside `ipx-directory`:
       - /mnt/fast/appdata/ipx-play:/config
     ports:
       - "8102:8102"
-      - "9189:9189"   # /metrics, for Prometheus on the LAN; not in the tunnel
+      - "9191:9191"   # /metrics, for Prometheus on the LAN; not in the tunnel
 ```
 
 Its config, `/mnt/fast/appdata/ipx-play/play.toml`:
@@ -48,7 +48,7 @@ bind = "0.0.0.0:8102"
 public_url = "https://play.ipxreader.app"
 # Prometheus metrics, on a port of their own and not the one the tunnel publishes. Empty, or
 # left out, serves none.
-metrics_bind = "0.0.0.0:9189"
+metrics_bind = "0.0.0.0:9191"
 
 # One for each ipx server allowed to make links; `ipx-play token <name>` prints the lines.
 [[tokens]]
@@ -79,7 +79,7 @@ Prometheus's config:
 ```yaml
   - job_name: ipx-play
     static_configs:
-      - targets: ["192.168.1.130:9189"]
+      - targets: ["192.168.1.130:9191"]
 ```
 
 `play_http_request_duration_seconds{method,route,status}` (a page opened is `route="/e/{id}"`, an