fix(navigation): keep the stack alive when the unwind target is absent

[EugeneSusla]

The bug

Logging an intake from a recipe leaves the app on a black screen. The
intake itself is saved correctly — only the screen after it is lost.

The two unwinds that run at the end of the logging flow name a route that
is not always on the stack:

• edit_meal_screen.dart:911 — pushNamedAndRemoveUntil(mealDetailRoute, ModalRoute.withName(addMealRoute))
• meal_detail_bottom_sheet.dart:319 — popUntil(ModalRoute.withName(mainRoute))

ModalRoute.withName(x) matches nothing when x is absent, and both
popUntil and pushNamedAndRemoveUntil respond to a predicate that never
matches by removing every route. An empty navigator renders as a black
screen with nothing to navigate back to.

Reachable chain

1. Recipes tab → a recipe → Log → pick an intake type.
   recipe_detail_screen.dart:247 pushes mealDetailRoute. Nothing on
   this path pushed addMealRoute, so the stack is [main, mealDetail].
2. On that meal detail, the edit pencil
   (meal_detail_screen.dart:300-311) pushes editMealRoute with an
   EditMealScreenArguments that passes no editOnly. It defaults to
   false → the create-and-log save path.
3. Saving runs the unwind at edit_meal_screen.dart:911. No addMealRoute
   matches, so every route below the new meal detail is removed — main
   included. The stack is now [mealDetail].
4. The intake sheet's Add (meal_detail_bottom_sheet.dart:319) writes
   the intake, then runs popUntil(withName(mainRoute)). No match, so it
   pops the last remaining route. Empty navigator → black screen.

The other Edit Meal entry points are not affected, which is why this went
unnoticed: recipes_page.dart:164 and custom_meals_tab.dart:160 both
pass editOnly: true and therefore pop() instead of unwinding, and
add_meal_screen.dart:530 reaches Edit Meal with addMealRoute genuinely
on the stack.

The fix

namedRouteOrFirst(routeName) — (route) => route.isFirst || route.settings.name == routeName.

isFirst is the right floor because the main screen is the first route
once the app is running: splash_screen.dart:67 reaches it with
pushReplacementNamed, and the onboarding exits
(onboarding_screen.dart:150, :505,
onboarding_intro_page_body.dart:220) replace or clear the stack the same
way. So a stack that has no mainRoute by name still has the main screen
at the bottom, and stopping there is what the unwind was aiming for
anyway.

The predicate deliberately does not assert that the first route is main.
Landing on the bottom route beats an empty navigator in every case, and
for the addMealRoute call site the first route is legitimately something
else.

activity_detail_screen.dart:323 carried the identical
popUntil(withName(mainRoute)) and is fixed defensively — it is only
reachable after step 3 has already removed main, so it cannot empty
the stack on its own today, but it would break the same way if it ever
could.

Tests

test/features/edit_meal/presentation/edit_meal_unwind_test.dart drives
the real chain: the real MealDetailScreen's edit pencil, the real
EditMealScreen's save, and the real MealDetailBottomSheet's Add, on
the [main, mealDetail] stack a recipe log leaves behind. Only the main
screen is stubbed — all these unwinds want from it is a route named main
to survive.

Run unchanged against develop it reproduces the whole bug: the intake is
written, the navigator ends up empty, and nothing renders at all.

test/core/utils/navigation_predicates_test.dart covers the predicate
directly, including a test that pins Flutter's stack-emptying behaviour —
kept on purpose, as the signal for when this helper can be deleted.