Read a row's seat order from the venue drawing, so a curved row stops claiming its two ends are adjacent

A place's position is what every adjacency question in yoyaku_placement is answered from: PlaceGeometry::run() is consecutive positions, fragments() breaks where they skip, and Together seats a party together by taking them side by side. So a position is not a label and not a sort key. It is the claim that two seats touch, and nothing downstream can check it.

Nothing derives it. Positions arrive with the venue, and a hall drawn on a plan is easy to number by sorting on x, which is right for a straight row and wrong for every row that turns: a balcony sweeping round the hall runs out of width and starts to climb, so an x-sort interleaves its two halves. Eleven rows of the bundled Auditorium de Bordeaux package are numbered that way. Its worst pair sits 1986 map units apart while holding consecutive positions.

Reproduced: a party of twelve booked across three tariffs was seated in two clumps a third of the hall apart, in one section and on consecutive positions, and reported as sitting together. The seating strategy was reading the positions correctly; the positions were the lie.

A second defect with the same cause: positions have to run 1, 2, 3 within one area, because that is the only shape a run is read from, and a printed row numbered straight through when part of it belongs to a subsection leaves each half full of holes. The Auditorium's balcony had positions 1 to 9, then 12, 15, 19, 21 in one area, so a row of thirty-four free seats could not offer a run longer than nine.

Note that the printed place number cannot be the ordering either: 35 rows of the same package are numbered outwards from the middle, so seats 1 and 2 sit beside each other at the centre, and some places are not numbered with numbers at all (35b).

Proposed fix

• A RowPath service that recovers a row's order from the drawing: walk from one of the row's two ends (the furthest apart pair) to the nearest seat not yet walked. Which end comes first is not a geometric question, so the direction the venue already numbers in is kept, read from the whole row rather than from whichever seat holds position 1.
• A PlacePositions service that reports the rows disagreeing with the drawing, and renumbers them 1..N per area. Only places that actually move are saved, so a correct hall is untouched and running it twice changes nothing.
• Importing a venue package derives a drawn row's positions and logs how many rows it corrected.
• drush yoyaku:venue-positions <venue> to check (exits non-zero on drift, so a deploy can gate on it) and --fix to repair.
• A Numbering tab on the venue that draws each row threaded in position order, since neither defect is visible from a list of places. An unbroken line follows the row; a line that doubles back does not.
• The shipped Auditorium package corrected: 265 places across 11 scrambled rows and 2 with holes.

No change to any seating strategy or to PlaceGeometry: they were reading the data correctly. No change to the booker's map payload either, since the drawing already carried position.