feat(deploy): bake custom_models into a thin GraphHopper image

[cafca]

Summary

Replace the host-side bind mount of backend/custom_models/ with a thin custom GraphHopper image that copies the directory in at build time. Routing rules now ship atomically with docker compose pull — no host scp, no "did the file reach the server?" failure mode.

CD also gains a post-deploy probe that wipes the GH cache only when actually needed (i.e. when the new image carries a different profile hash from the one baked into the existing graph cache).

Changes

backend/graphhopper.Dockerfile (new):
```dockerfile
FROM israelhikingmap/graphhopper:latest
COPY backend/custom_models/ /custom_models/
```

compose.prod.yml: switch GH service to ghcr.io/cafca/beebeebike-graphhopper:latest. Bind mount of backend/custom_models is unnecessary (file is in the image now).

.github/workflows/cd.yml:

• Build and push the GH image alongside the backend image (separate buildx cache scope so it doesn't bust backend builds).
• After docker compose up -d, sleep 12s and grep recent GH logs for does not match. If found → stop GH, wipe data/osm/berlin/graphhopper, restart for a fresh import. Otherwise leave the cache alone.

Why

Today the routing rules live as a host file shipped via two separate paths (the scp source: list, and a compose.prod.yml bind mount). When PR #72 merged, both paths needed updates — neither got them — and prod GH crash-looped until the file was scp'd manually.

With the rules inside the GH image:

• One image, one source of truth for the runtime that consumes it.
• Rollback is automatic: docker pull an old tag and you get the matching custom model.
• docker compose pull && up -d is the only deploy verb again.

Why the conditional cache wipe (vs. always wipe / vs. never wipe)

GraphHopper bakes the profile hash (priority/speed/distance_influence/turn_costs) into the imported graph. On boot it compares the configured hash to the stored one:

• match → loads cache, ~10s startup.
• mismatch → refuses to start: Profile 'bike' does not match.

Always-wiping turns every backend-only deploy into a multi-minute GH outage. Never-wiping breaks deploys that change the profile. The crash-loop signature is unambiguous, so detecting it post-up -d is reliable and lets the common path (model unchanged) stay fast.

Notes for reviewers

• Supersedes fix(deploy): mount and sync backend/custom_models to prod #73. Once this lands, fix(deploy): mount and sync backend/custom_models to prod #73 can be closed without merging — the host bind mount approach is obsoleted.
• The israelhikingmap/graphhopper:latest base is pinned to latest to match current behavior; consider pinning to a tag in a follow-up.
• graphhopper_config.yml stays host-mounted because it changes more often than custom models and we don't want a CD round trip for config-only edits. Could revisit later.
• First post-merge deploy will trigger the cache wipe (because helena's current cache was baked against the manual deploy I did yesterday with hash X, and the image-driven deploy will have hash X' even if the bytes are identical — distinct mount source = distinct hash for some GH builds; safer to assume wipe).

Test plan

• CI build + push both images successfully on a force-push to a test branch.
• Image pulls and starts cleanly on helena.
• After this PR's deploy, prod GH logs show successful reimport (cache wipe path triggered once, then steady).
• Subsequent backend-only deploys do not wipe the cache and don't fire the wipe path (verify by deploying a no-op backend change and checking CD logs for Profile hash mismatch detected).