Point production at the LAN MongoDB (192.168.1.7:27017)

Production uses the network's database server instead of a mongo service
inside the stack (the compose-managed one never served the API). Dev is
unchanged: backend/.env keeps localhost:27017.

- docker-compose.yml: MONGO_URI=mongodb://192.168.1.7:27017/mathew; drop
  the in-stack mongo service, its volume and the healthcheck gate
- deploy.yml: up -d --remove-orphans so yesterday's mongo container is
  retired when the new compose lands

AGENTS.md

@@ -29,8 +29,9 @@ Seed sample articles: `npm run seed` in `backend/`.
 Environment: `backend/.env` (`PORT=5000`, `MONGO_URI=mongodb://127.0.0.1:27017/mathew`,
 `JWT_SECRET` — signs session tokens, `AUTH_TOKEN_TTL` — how long one lasts, default `7d`;
 see `.env.example`). Without `JWT_SECRET` the API warns and uses an insecure dev key.
-Production (`docker-compose.yml`) runs MongoDB as its own `mongo` service (volume `mongo-data`)
-and passes the backend a `MONGO_URI` by service name; `JWT_SECRET` interpolates from
+Production (`docker-compose.yml`) points the backend at the LAN MongoDB server
+(`MONGO_URI=mongodb://192.168.1.7:27017/mathew`; development keeps `localhost:27017` via
+`backend/.env`); `JWT_SECRET` interpolates from
 `/var/www/app/.env` on the deploy host (create it once — the public site must not sign sessions
 with the dev key). The stack's nginx resolves `backend`/`frontend` through Docker's DNS per
 request, so container recreates cannot leave it on a stale IP.