Canteen Management

Real gap found while scoping D32 (no written plan named a task for this day): nothing in the Dietary module reacted when a synced dietary order left Active status. MealSheetService and DietChargeAccrualService both already filter on Status == "Active" when generating new work, but a tray already created for an order BEFORE it was discontinued (e.g. on discharge, or a diet change) just sat as Planned forever -- nobody told the kitchen to stop cooking for it.

Fix is pure local logic, no new cross-team contract needed -- the Active/Discontinued status is already synced in via D22/D23's poller into DietaryOrderSnapshot.

Shipped:

• ITrayService.SkipOutstandingForOrderAsync(hospitalId, dietaryOrderId, by) -- skips every still-Planned tray for an order; trays already Plated or further along are left untouched (food already prepared is a different, non-automatic decision, same cut-off HandleAdmissionTransferAsync already uses).
• Wired from DietOrderSyncService.UpsertSnapshotsAsync: captures a snapshot's status before applying the contract's update, and on an Active -> not-Active transition calls the new method. A brand-new order, an order that stays Active, and an order re-polled while already discontinued all correctly trigger nothing -- only the actual transition fires it once.
• Caught and fixed a dormant hospital-scoping bug before it could ship: TrayService is a CanteenManagementService reading CurrentHospitalId from IHospitalContext, but the only caller runs from a background poll with no HTTP context (same class of bug DietChargeAccrualJob's own doc comment describes) -- the new method takes hospitalId as an explicit parameter instead, and its audit write is built directly rather than through the AuditAsync helper that would have silently stamped HospitalId 0.

13 new/updated backend tests.