Plot routes and build the jump-link graph in a Web Worker

Route plotting ran on the main thread, and so did the jump-link graph:

- the range search for a far target, HD 2626 at 236 pc, takes 4-5 s;
- the graph at 8 pc is 3.7 million links, 6-10 s to build, then as many
  link objects again to turn into vertices.

The map stopped for as long as either ran.

A Web Worker now does both. RoutingClient sends it the catalogue's ids and
positions once, and it keeps its own spatial index. A route question comes
back with the route, or with the range that would open one. A graph comes
back as one Float32Array of segment vertices, transferred rather than
copied.

On the scene side, only the latest route request is shown: an earlier
answer arriving later is dropped. Only the graph for the range last asked
for is drawn. The Routes panel says "Plotting…" and holds its button while
a request is out.

collectJumpLinks gave way to jumpLinkSegments, which writes the vertex pairs
straight into floats rather than building link objects first; the scene was
its only caller. The routing module (routing.ts) is the message protocol and
the one function answering it, so the worker is a dozen lines, and the same
answers are worked out in place where there is no Worker, as in the unit
tests' DOM. The worker is built with its own tsconfig, as the Angular
builder expects.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi

src/app/shared/astro/routing.ts

@@ -0,0 +1,48 @@
+/**
+ * The route questions the map asks of the whole catalogue, as messages: what a worker is sent,
+ * what it sends back, and the one function that turns the first into the second.
+ *
+ * Kept apart from the worker itself so it runs the same on either side of the thread boundary.
+ * The scene asks through `RoutingClient`, which hands these to a Web Worker where one exists and
+ * answers them in place where one does not.
+ */
+
+import { jumpLinkSegments, minimumRangeBetween, Route, routeBetween } from './jump-links';
+import { StarNeighbourhood } from './star-neighbourhood';
+
+/** The catalogue, sent once: ids, and positions packed three to a star in the same order. */
+export interface RoutingCatalogue {
+  readonly kind: 'catalogue';
+  readonly ids: Int32Array;
+  readonly positions: Float32Array;
+}
+
+export type RoutingRequest =
+  | { readonly kind: 'route'; readonly requestId: number; readonly fromId: number; readonly toId: number; readonly rangePc: number; readonly ceilingPc: number }
+  | { readonly kind: 'links'; readonly requestId: number; readonly rangePc: number };
+
+export type RoutingResponse =
+  | { readonly kind: 'route'; readonly requestId: number; readonly route: Route | null; readonly neededRangePc: number | null }
+  | { readonly kind: 'links'; readonly requestId: number; readonly segments: Float32Array };
+
+/** A spatial index over a catalogue sent as a {@link RoutingCatalogue}. */
+export function indexCatalogue({ ids, positions }: RoutingCatalogue): StarNeighbourhood {
+  return new StarNeighbourhood(Array.from(ids, (id, i) => ({ id, x: positions[i * 3], y: positions[i * 3 + 1], z: positions[i * 3 + 2] })));
+}
+
+/**
+ * Answers one request. A route that cannot be made comes back with the range that would make
+ * one, searched no wider than `ceilingPc`, so a refusal is always also an offer.
+ */
+export function answerRouting(index: StarNeighbourhood, request: RoutingRequest): RoutingResponse {
+  if (request.kind === 'links') {
+    return { kind: 'links', requestId: request.requestId, segments: jumpLinkSegments(index, request.rangePc) };
+  }
+  const route = routeBetween(index, request.fromId, request.toId, request.rangePc);
+  return {
+    kind: 'route',
+    requestId: request.requestId,
+    route,
+    neededRangePc: route ? null : minimumRangeBetween(index, request.fromId, request.toId, request.ceilingPc)
+  };
+}