Backlog: add route drawing, split server work into v4

Route drawing promoted to a full section. The key point is that road-snapped
shortest path needs a routing engine, and that is the whole decision -- OSRM,
GraphHopper or Valhalla self-hosted, or commercial with a key in the app.
Profiles matter more than usual here, since a motorcycle route and a bicycle
route between the same pins genuinely differ, which is where activity type pays
off. Also flagged that a routing engine's ETA is based on posted limits, not on
how fast the rider actually goes -- and the app already stores enough history to
do better.

Group rides, accounts and paid cloud backup moved out to a new v4 section. They
are one programme, not three: each needs a server, identity and a privacy stance,
and none is worth building alone. Recorded that live positions want a websocket
alongside the existing batched uploader rather than replacing it, since the batch
path is what guarantees no fix is lost -- and that location sharing is a consent
question, not a feature.

Renamed V3-BACKLOG.md to BACKLOG.md, since it now covers both, and made the
split explicit up front: v3 is everything buildable with no server, v4 is
everything that cannot be. That means v3 can proceed indefinitely without anyone
deciding to run infrastructure or hold other people's location data.

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

docs/LAUNCH.md

@@ -121,7 +121,7 @@ Everything in Stage 1, plus the parts that are genuinely work.
 
 Everything user-facing currently says motorcycle, but the recording pipeline is entirely
 activity-agnostic — it records positions and speeds, and nothing in it cares what you are
-sitting on. `V3-BACKLOG.md` already carries **activity type per ride** as an idea.
+sitting on. `BACKLOG.md` already carries **activity type per ride** as an idea.
 
 That matters here rather than only in the backlog, because it decides the store category,
 the screenshots and who finds the app. Cyclists are a far larger audience than