deploy: split build into docker-compose.dev.yml overlay

Make the base docker-compose.yml strictly production-shaped — image: only, no
build: — so a production host can only ever pull, never accidentally build
(compose gives build precedence for `up --build`/`build`, which mixed the two
modes). Local builds move to an explicit, non-auto-loaded overlay.

  Production:   docker compose pull && docker compose up -d
  Development:  docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

Verified with `docker compose config`: base renders image-only (no build) for
both services; the dev overlay adds build back (app -> Dockerfile,
bot -> bot/Dockerfile). README quick-start updated to the two-file flow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ

docker-compose.dev.yml

@@ -0,0 +1,24 @@
+# Development overlay — build the app + bot images locally instead of pulling the
+# prebuilt ones from the Gitea registry.
+#
+# The base docker-compose.yml is production-shaped (image: only, no build:), so a
+# production host can never accidentally build — it only pulls. Use this overlay
+# EXPLICITLY for local work (it is not auto-loaded like docker-compose.override.yml
+# would be):
+#
+#   docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build
+#
+# Production stays:
+#
+#   docker compose pull && docker compose up -d
+#
+# The `image:` tags inherited from the base file double as the local build tags,
+# so a built image and a pulled one are interchangeable.
+services:
+  app:
+    build: .
+
+  bot:
+    build:
+      context: .
+      dockerfile: bot/Dockerfile