Carry a message type rather than an error boolean

Every message the booking stepper showed carried a boolean rather than a type, so the only two things it could be were an error and not-an-error. The stylesheet already said what the two states really were: the base rule was amber and its comment read "still reading as a warning rather than as an error". So the false half was not an absence of a type, it was a warning, and what had no way to be said at all was a plain confirmation.

What shipped

Drupal\yoyaku\BookingMessage carries a text and a type, the type being one of core's own MessengerInterface::TYPE_STATUS, TYPE_WARNING and TYPE_ERROR. Type rather than level, because that is core's noun for it.

• UnitAssignment::$messages and BookingResult::$messages replace the two $notices arrays, both typed. The placement seam sets the type, since it is the layer that knows which sentence is which, and the engine carries it out untouched.
• OfferClaim::getMessages() is gone, and so is the conversion it existed for. SelectionBooker answers with one messages list rather than errors plus notices, so the two forms that read it each lost a loop: they call addMessage($message->text, $message->type) and let the messenger take the type as it stands.
• Both JSON envelopes carry messages with the type: the API client's order representation and the seat map's answer.

The type that had no producer now has one

Three sentences come out of the placement, and they were not the same kind of news. "Your places have moved to the part of the house you asked for." is a confirmation of what the booker asked for, so it is a status; "Your places are in another row now." and the seating's report of how close together it managed are warnings. All three were being flattened to a warning one step later, which is why the first showed amber.

The seat map had the same fault from the other end. It showed every one of these as a status, so the identical "we could not seat you side by side" sentence was green on the plan and amber on the price list. It reads the type now, and the two surfaces agree.

On the client

Drupal.yoyaku.say() is gone. Core has no say(); it has Drupal.Message, so there is Drupal.yoyaku.Message, method for method: new Drupal.yoyaku.Message(region), then add(message, {type, id}) and clear(). The one deliberate divergence is that there is no defaultWrapper() to fall back to: a booking page's messages sit beside the control that produced them, and a message about one offer said at the top of the page names no offer.

The type maps to a class rather than selecting one of two, so each of the three names its own rule. The colors are unchanged for the two types already in use, and the sentence still says which it is: the color is never the only thing carrying the difference.

It decides how urgently the region is read out as well, which is the half nobody sees go wrong. Both surfaces now go to role="alert" while anything the booker is waiting on is standing in the region and back to role="status" while it is all notes about what was done, which is core's rule and what the seat map already did. The offer card was fixed at status, so a refusal was announced politely to a booker sitting there waiting to know whether they held the place.

Telling the three apart without relying on color at all is #3619803: Tell the three message types apart without relying on color.

Notice is no longer a word this module uses

The last of the old vocabulary went with it, on both surfaces and in the settings: the region and its lines, the DOM ids, and the notice_seconds setting, which is message_seconds now. Two booker-facing strings moved with it and the French catalog is updated in the same commit.

The setting is a config key, and config/install does not reach a site that is already installed, so a site that had set the old key falls back to the five second default until it is reinstalled or the key is set by hand. The project is before 1.0 and reinstall-only, so there is no update hook.

Not in scope

The error key on the JSON response envelopes several controllers return beside ok. That is a failed request carrying its reason, not a message with a type, and a sweep on the bare word would corrupt it.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its test coverage. I reviewed both. Every code, stylesheet and measurement reference above was verified against the branch, and the pipeline was read job by job on both the current and the next-major lane.)