feat: order a rider's stops using the Route Optimization API

Assignment decided who carried a booking but never what order to run
several of them in -- the one capability jupiter had that Doormile did
not. It turns out we already own the solver: routes.workolik.com is a
live in-house Route Optimization API backed by Valhalla road-network
routing, not the paid third party I had assumed. This is a client for
it, not a solver.

internal/routing posts a rider's active stops and writes back step,
previouskms, cumulativekms and ETA onto BookingAssignment. HubBatchAssign
calls it after committing a batch, which is exactly the case it exists
for: a rider used to walk away with several bookings and no order to run
them in. GetMilerAssignments now returns sequenced stops in step order,
falling back to newest-first for anything unsequenced.

Contract discovered by probing the live service -- the OpenAPI schema
types the body as a bare object array, so the field names are not
documented anywhere. They are pickuplat/pickuplong/deliverylat/
deliverylong, NOT pickuplatitude/deliverylatitude. Sending the wrong
names does not fail: it returns HTTP 200 with every coordinate defaulted
to "0.0", no reordering and all distances zero. That trap is recorded in
a comment so the next person does not lose an afternoon to it.

Numeric fields come back inconsistently typed -- previouskms as a number,
actualkms and eta as strings, some decimal -- so they are decoded loosely
and coerced, with tests pinning the coercion. Steps for deliveryids we
did not send are discarded rather than written, so an echoed or stale id
cannot reorder another rider's work.

Sequencing is best-effort throughout and runs after assignments commit.
The optimizer is a separate service over the network; it being down must
leave bookings assigned but unordered, never undo the batch. Step 0 means
"not sequenced", not "first".

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

controllers/hubController.go

@@ -13,6 +13,7 @@ import (
 	"doormile/db"
 	"doormile/dto"
 	"doormile/internal/assignment"
+	"doormile/internal/routing"
 	"doormile/models"
 	"doormile/utils"
 
@@ -2018,13 +2019,54 @@ func HubBatchAssign(c *fiber.Ctx) error {
 		assignedCount++
 	}
 
+	// Batch assignment is exactly the case stop-ordering exists for: a rider
+	// walks out of here with several bookings and, until now, no indication of
+	// what order to run them in. Sequence each rider that actually got work.
+	//
+	// Best-effort and deliberately after the assignments are committed: the
+	// optimizer is a separate service over the network, and it failing must
+	// leave the bookings assigned rather than undoing the batch.
+	sequenced := 0
+	for _, r := range ridersAssigned(results) {
+		if _, err := routing.SequenceMilerStops(r); err != nil {
+			utils.Warn("HubBatchAssign: stop sequencing failed",
+				"miler_userid", r, "error", err)
+			continue
+		}
+		sequenced++
+	}
+
 	return utils.OK(c, fiber.Map{
-		"assigned": assignedCount,
-		"skipped":  skippedCount,
-		"results":  results,
+		"assigned":        assignedCount,
+		"skipped":         skippedCount,
+		"riderssequenced": sequenced,
+		"results":         results,
 	})
 }
 
+// ridersAssigned pulls the distinct miler user ids out of a batch result set,
+// so each rider is sequenced once rather than once per booking they received.
+func ridersAssigned(results []fiber.Map) []int {
+	seen := make(map[int]struct{})
+	var ids []int
+	for _, r := range results {
+		ok, _ := r["assigned"].(bool)
+		if !ok {
+			continue
+		}
+		id, isInt := r["mileruserid"].(int)
+		if !isInt {
+			continue
+		}
+		if _, dup := seen[id]; dup {
+			continue
+		}
+		seen[id] = struct{}{}
+		ids = append(ids, id)
+	}
+	return ids
+}
+
 // --------------------
 // HUB REPORT EXPORT
 // --------------------

controllers/milerController.go

@@ -326,9 +326,14 @@ func GetMilerAssignments(c *fiber.Ctx) error {
 	milerUserID := c.Locals("userid").(int)
 
 	var assignments []models.BookingAssignment
+	// Sequenced stops come first, in the road order internal/routing worked out,
+	// because that is the order the rider should actually ride them. Anything
+	// not yet sequenced (step 0 — a single stop, or the optimizer being
+	// unreachable) falls back to newest-first, which is the old behaviour.
 	if err := db.DB.Where("mileruserid = ? AND assignmentstatus IN ?", milerUserID,
 		[]string{constants.AssignmentAssigned, constants.AssignmentAccepted}).
-		Order("assignedat DESC").Find(&assignments).Error; err != nil {
+		Order("CASE WHEN step > 0 THEN 0 ELSE 1 END ASC, step ASC, assignedat DESC").
+		Find(&assignments).Error; err != nil {
 		return utils.Internal(c, "failed to fetch assignments")
 	}