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>

docker/brouter/Dockerfile

@@ -38,9 +38,16 @@ EXPOSE 17777
 # The default keeps the flagship's single-instance footprint small.
 ENV JAVA_OPTS="-Xmx1024M -Xms256M -Xmn64M"
 
+# Routing thread pool. When saturated, BRouter's thread-priority watchdog
+# kills the oldest in-flight request ("contention! ms killed …") to free a
+# thread for the new one — the caller then sees a cancelled response. Bump
+# this on hosts with spare cores/RAM to absorb burst traffic. Planet host
+# sets it to 16; flagship/CI keep the default.
+ENV BROUTER_THREADS=4
+
 # BRouter server: <segmentdir> <profiledir> <customprofiledir> <port> <maxthreads>
-# Shell form so $JAVA_OPTS expands at container start.
+# Shell form so $JAVA_OPTS and $BROUTER_THREADS expand at container start.
 CMD java $JAVA_OPTS -DmaxRunningTime=300 -cp brouter.jar \
     btools.server.RouteServer \
     /data/segments /data/profiles /data/profiles \
-    17777 4
+    17777 $BROUTER_THREADS