## Context

See proposal.md - Why. `LunchBookingMenu::items()` is a `belongsToMany` to `LunchItem` through `lunch_booking_menu_item`; there is no inverse relation on `LunchItem`. Menu status (`coming`/`available`/`completed`/`cancelled`) is already kept realtime-accurate by `LunchBookingMenu::updateStatus()` and the `autoUpdateStatusBooking` scheduled task, so filtering on the stored `status` column (rather than recomputing from `started_at`/`closed_at`) is consistent with how the rest of the package already treats "is this menu open".

## Goals / Non-Goals

**Goals:**
- Give the FE a single call to answer "is this item safe to reprice without affecting an in-flight menu?".

**Non-Goals:**
- Blocking or warning server-side when a price update happens while the item is attached to an open menu - this change only exposes the data; any warning/confirmation UX is FE's decision (per the FE doc, this is exactly what they asked for).
- Historical/closed menus - only `coming`/`available` menus are relevant to the warning use case.

## Decisions

**1. A dedicated `GET /admin/lunch-items/{id}/active-menus` endpoint, not an `item_id` filter on `GET /admin/lunch-menus`.**
The FE doc offered both options. A dedicated endpoint is a smaller, purpose-built read (no pagination/sorting/date-filter concerns to reconcile with an existing, more general list endpoint) and matches the FE's own "lighter" suggestion. Alternative considered: add `item_id` to `LunchMenuController::index()` - rejected as unnecessary generality for a single, specific warning check.

**2. Response includes the matching menus (not just a count).**
A count alone answers "should I warn", but the FE doc's own justification ("để admin biết") implies the admin may want to know *which* menu(s) - e.g. to jump to it. Returning `{ count, menus: [...] }` (id, display_name, started_at, closed_at, status) satisfies both a cheap boolean check (`count > 0`) and a richer tooltip/list without a second call.

**3. Reuse the existing `lunch_items_index` permission.**
This is a read-only, informational lookup scoped to an item an admin can already view - no new permission is warranted.

## Risks / Trade-offs

- **[Race with status cron]** `status` is updated by a scheduled task rather than computed live, so there is a small window where a menu that just passed `closed_at` still reads as `available` → Mitigation: pre-existing, accepted behavior everywhere else in the package that relies on `status`; not specific to this feature.