Canteen Management

The cook sheet's "Served so far" column was hardcoded to 0 -- nothing in the module connected a completed POS sale back to the production plan, even though ProductionPlanLine already carried ActualServed/RecordServed for exactly this, unused.

Added ProductionConsumptionPoster (Production), a static helper over the caller's CanteenManagementDbContext, same pattern as EmployeeAccountLock/CouponLock. PostAsync resolves the slot the sale completed in (reusing MealSlotSchedule.CurrentAt -- the same cut-off logic the POS quote's "what's being served" header already uses), looks up each sold line's recipe via MenuItem.RecipeId, and atomically increments ProductionPlanLine.ActualServed (ExecuteUpdateAsync, not load-modify-save, so two tills selling the same recipe into the same slot at once can't lose a count -- same pattern as CouponBook.RedeemedCount). ReverseAsync undoes exactly what was posted.

Sale gets a new ConsumptionMealSlotId snapshot set at posting time, so a void approved during a later slot's service still reverses into the slot the sale actually posted to. SaleService posts best-effort right after completion (a kitchen-count write must never fail or roll back a paid sale's response; failures are caught and audited as ProductionConsumptionPostFailed, never thrown). SaleVoidService reverses inside the void's own transaction, alongside the existing employee-account/coupon reversals.

Silently skipped, not an error: a menu item with no recipe (packaged goods), and a recipe with no patient demand that slot (no ProductionPlanLine row exists yet -- the same documented Canteen-forecast gap, not a new one).

8 new ProductionConsumptionPosterTests, one wiring test each in SaleServiceTests/SaleVoidServiceTests proving the real end-to-end call. 1053/1055 backend, 585/585 frontend.

Commit (pushed under the wrong Redmine number, #398; corrected here): dc892a0.