[Connor-Finn]

Part 3 of #328. Closes #328.

What changed

• Fix: editing a shipment no longer cuts its orders off their drop stops. syncShipmentStops used to delete and recreate every stop on any edit of a draft with waypoints (the edit page always sends them), so orders silently lost their deliveryStopId and could never be marked delivered. It now reconciles: stops still on the route keep their row and are renumbered, new locations get new stops, and stops off the route are deleted. Removing a stop that orders still drop at is refused (StopStillHasOrdersError).
• Adding an order to an existing shipment: a new drop goes in before the destination, stops are renumbered 1..n, and shipment.updated is emitted, so a custom route is re-planned.
• Combine/convert (API): the new shipment goes on a lane only when one matches its stops exactly and supports its service level (assignMatchingLane); otherwise it stays a custom route and gets a planned route.
• PUT /api/v1/shipments/:id accepts laneId: null, taking a shipment off its lane.
• Shipment page: a draft or ready lane shipment whose stops don't match its lane shows a warning, with "Switch to custom route" and "Save as new lane".

Testing

• Full backend suite (2,426), frontend tests, both type-checks, tenancy and boundary lints pass.
• Live against a seeded database:
  • the warning showed on a lane shipment with an extra Rochester drop
  • "Save as new lane" created the lane with that stop and kept both orders on their drops
  • switching to a custom route cleared the lane with stops and order links intact
  • adding an order to a custom-route shipment inserted its drop before the destination, renumbered the stops and re-ran route planning

🤖 Generated with Claude Code