Issue #3618305: Admin screens do not say what a record belongs to, and a translation cannot be saved

Six faults of one shape, found by using the translation and arranging screens for an afternoon. Two commits.

hook_yoyaku_owning_references() is the new seam: each module states what IT owns, and three readers use that one map -- the form, the breadcrumb and the after-save destination. The mechanism sits in the engine rather than in yoyaku_ui, because placement declares its own screens and does not depend on the admin UI module; with it there, the rule held for a slot tariff and not for a place grade, which is the same rule.

The owning reference is shown with its widget LEFT IN PLACE and inaccessible, so core takes the stored value as the submitted one and the reference round-trips. Verified by re-saving over HTTP and reloading, not by reading the form array.

Two traps worth naming:

• $entity->toLink() asks for the canonical template and throws without one. These types only have one where content_translation is installed, so a breadcrumb built on it is an exception on every site without it. Only the kernel test saw that, because its module list has none.
• A read-only item put where a widget was needs a FRACTIONAL weight: it is added last, another field can share the weight (a resource tariff's price shares -5 with its resource), and a tie is broken by insertion order.

The machine name fix is the one that was blocking work outright: core's default pattern allows letters, numbers and underscores while this module writes hyphens, so a row keyed full-price was refused on every one of its forms. The module's own fixtures create full-price, grille-a and cat1-full, which is what settles that the pattern was wrong rather than the data. No key is renamed.

Tests pin what this module decides, and each was seen failing with its fix switched off. Verified end to end against a running multilingual site: eleven forms, every venue tab, the translation screens, and a hyphenated tariff class saved and translated.