Stop BRouter contention kills under rapid editing

When a user rapidly moves waypoints in the Planner, BRouter's
thread-priority watchdog kills older in-flight requests to free a thread
for newer ones, surfacing to the user as "operation killed by
thread-priority-watchdog" errors.

Two fixes:

1. Bump the BRouter thread pool on the dedicated host from 4 to 16.
   `BROUTER_THREADS` is now a Dockerfile ENV (default 4 for
   flagship/CI/dev) overridden to 16 in `infrastructure/brouter-host/`.
   The host has 32 GB of RAM and idle cores; 4 threads was a flagship-era
   constraint that no longer applies.

2. Cancel the previous in-flight `/api/route` request when a new one
   starts. `use-routing.ts` now keeps an `AbortController` in a ref,
   aborts it at the top of each `computeRoute`, and bails quietly on
   `AbortError` so the newer call drives state.

Together these eliminate both the "real" contention (at the BRouter
level) and the wasted work (BRouter computing a route the client no
longer cares about).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

infrastructure/brouter-host/docker-compose.yml

@@ -19,8 +19,12 @@ services:
     # Planet-scale coverage: segments live on the host and are mounted in.
     # 8 GB heap for segment cache; -Xms generous because routing is
     # memory-heavy and we don't benefit from a slow JVM warmup.
+    # 16 routing threads on the 32 GB / multi-core dedicated host absorbs
+    # burst traffic from "click around wildly" editing without triggering
+    # BRouter's contention watchdog on the 4-thread default.
     environment:
       JAVA_OPTS: "-Xmx8g -Xms512M"
+      BROUTER_THREADS: "16"
     volumes:
       - ./segments:/data/segments:ro
     networks: