Numbered/assigned seating submodule (yoyaku_seating)

Yoyaku's capacity is a count per category (a pool, for example "20 places in the Child tier"), not a set of individually identified units. Numbered or assigned seating - a specific seat A12 that exactly one person can book - is therefore not first-class: there is no seat entity, no seat attributes (row, section, accessible, adjacency) and no seat map.

Workaround available today: model each seat as a category with capacity 1. That gives exclusivity and the engine's atomic, concurrency-safe reservation under the slot-row lock, and is fine for a handful of named units (tables, bays, meeting rooms). It does not scale to a large venue: hundreds of categories per slot, a quantity picker instead of a seat map, and no seat metadata.

Proposed: a yoyaku_seating submodule that adds identified seats as members of a category or section, with a booking referencing a specific seat and uniqueness enforced per (slot, seat). The hard part - atomic, race-safe reservation - is already provided by the core; seating adds identity plus a seat-map surface. It likely needs one small core seam: a primitive to reserve a specific unit, or a unique index on active bookings per (slot, seat).

This stretches the "bookable target shape" axis described in the use cases documentation (identified units versus pools). Pairs with the ticket generation and attendance check-in submodules discussed separately.