Rounding of the trip split can put a week-0 need on a later trip #75

TL;DR: Today the per-trip split can give the first trip zero packs although a first-trip recipe needs the food, so the copied list and the 2+ trip lines tell the user to buy it too late; this issue makes every trip that holds a need get at least its share.

Context

distributeRemainingAcrossTrips in menu_management/lib/shopping/trip_amount_distributor.dart splits whole units across trips with a largest-remainder rule. A small need on an early trip can round to 0. Example: 0.4 of a lemon on week 0 and 0.6 on week 1 round to 1 piece, all of it on week 1.

The copied list, the PDF and the on-screen 2+ trip lines all read this split. They then list the product under a later trip, and a week-0 recipe runs short.

PR #74 (issue #73) added a guard for the on-screen single-trip row only: it names the earliest trip that holds a TripItem for the ingredient. So in the rounding case the row says "buy now" while the copy lists the product under Week 2. Found during the review of #74.

Acceptance Criteria

• A trip that holds a TripItem for an ingredient never gets 0 units of it in the split, when the total allows at least one unit per such trip, or the units move to the earliest such trip.
• The copied list, the PDF and the on-screen rows name the same trip for each product in the rounding case.
• The single-trip guard added in fix: name the trip on a shopping row bought only on a later trip #74 stays correct, or is removed if the split fix makes it redundant.

Related Issues

• Shopping row hides the trip date when a product is bought only on a later trip #73
• fix: name the trip on a shopping row bought only on a later trip #74