Issue #3618361: A venue's twelve tabs are one row too long to read, and unreadable once translated

Folds the seven inventory screens of a venue under one Inventory tab, so the tab bar is two short rows rather than one unreadable one.

Entirely yoyaku_placement.links.task.yml: a parent task carrying base_route: entity.yoyaku_venue.edit_form and pointing at the sections route, and seven children carrying parent_id. That is core's own two-level shape, as config.export and the tasks under it. No routes, controllers or paths change, so every bookmark still opens and TranslationHooks::localTasksAlter() still moves the row onto the canonical name, where the Translate tab joins it: it rewrites base_route, which only the parent now has.

The name is not invented. VenueInventoryController serves exactly these seven screens and PlacementHooks::INVENTORY already calls them the inventory.

Verification. VenueTabGroupingTest asserts the top row, the second row in weight order, and that the group's tab has a route so it is clickable. Read through the local task manager rather than through markup, because the testing profile renders no tab bar and a page assertion here would pass whatever the tabs said. Seen to fail against unpatched code, then pass.

Two things worth knowing if you touch it: getLocalTasksForRoute() returns LocalTaskInterface objects, not arrays; and the second level is only built for the route being served, so both rows have to be read from one of the grouped screens, not from the edit form.

Also run: VenueRecordScreensTest and VenueInventoryOrderTest, the two classes that drive these screens. phpcs as CI runs it: 0. DrupalPractice: 0. phpstan: 0. cspell: 0 unknown words after the project dictionary.