fix(tours): long rides save, the horse route store stays bounded

A ride sends its full line with heights and every horse route section's
own line besides, about fifty bytes a point, so a ride along a few
thousand points of bridleway hit the API's 100kb body ceiling and the
save failed with a 413. Creating and editing a tour are now measured
against TOUR_WRITE_MAX_BYTES (2 MB), like the book and list file
routes; every other route, the tour copy among them, keeps 100kb.

The horse routes kept in memory are now bounded by section points as
well as by count (64 answers, 500k points), so panning a dense map can
no longer grow the server by hundreds of megabytes.

A search that found no connection can be asked again on the view whose
routes are shown, and a ride with a recorded time shows the horseshoe
beside its riding time instead of footprints.

shared/src/tours/tours.schema.ts

@@ -308,6 +308,13 @@ export type TourWaypointRole = z.infer<typeof tourWaypointRoleSchema>;
 export const TOUR_FIXED_LEG_MAX_POINTS = 5000;
 /** How far a fixed leg's ends may lie from the waypoints it joins, in metres. */
 export const TOUR_FIXED_LEG_END_TOLERANCE_M = 60;
+/**
+ * The largest body a tour create or edit may send, in bytes. A tour goes whole,
+ * its full line with heights and every fixed leg's line besides, at roughly
+ * fifty bytes a point: one horse route section at TOUR_FIXED_LEG_MAX_POINTS is
+ * a quarter of a megabyte on its own, far past the API's hundred kilobytes.
+ */
+export const TOUR_WRITE_MAX_BYTES = 2 * 1024 * 1024;
 
 const fixedLegGeometrySchema = z
   .array(z.tuple([z.number().finite().min(-90).max(90), z.number().finite().min(-180).max(180)]))