refactor(docker): default compose builds from Dockerfiles (baked deps, cached)

Chosen flow: build on the host from backend/scrobble Dockerfiles instead of
pulling from a registry (no registry / no Docker-on-dev needed). Heavy deps are
baked, so restarts are instant and rebuilds after git pull are cache-fast.
Removed the now-obsolete docker-compose.dev.yml (runtime-install variant); the
optional push-to-registry script stays for a future CI flow. Updated README,
CLAUDE.md, .env.example.

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

README.md

@@ -122,14 +122,13 @@ TICKETMASTER_API_KEY=  # optional — free key from developer.ticketmaster.com
 
 ### 2. Start
 
-Build the images on the host (simplest — no registry needed):
-
 ```bash
-docker compose -f docker-compose.dev.yml up -d
+docker compose up -d --build
 ```
 
-The default `docker-compose.yml` instead **pulls pre-built images** from a registry (faster restarts;
-set `REGISTRY`/`TAG` in `.env`, `npm run push-images` from a dev machine, then `docker compose up -d`).
+Builds locally from the Dockerfiles (deps baked in → instant restarts; rebuilds after a `git pull`
+are fast thanks to Docker's layer cache). No registry needed. (An optional pull-from-registry / CI
+flow exists too — `npm run push-images` + `REGISTRY`/`TAG` in `.env`, see `.env.example`.)
 
 Frontend on port 8080, backend on port 3700, scrobble service on port 3710. Route each through your reverse proxy. **Important:** the scrobble subdomain must *not* sit behind an SSO / forward-auth gateway — it authenticates itself via Navidrome (`ping.view`), and a gateway in front redirects the app's API calls to a login page.