Landing page for the Machines reference book.

Handles four actions, dispatched by live_action:

• :index — list of machines, backed by PhoenixKitManufacturing.ColumnConfig.Machines for configurable columns, per-column filters, sorting, and a saved view (persisted via PhoenixKitManufacturing.ViewConfigs). See Web.ColumnManagement.
• :types / :operations / :defect_reasons — redirect-only, as of the entities migration (dev_docs/ENTITIES_MIGRATION_SPEC.md). machine_type/operation/defect_reason CRUD now lives on the generic entities admin UI, so load_data/2 immediately push_navigates to the matching /admin/entities/:slug/data page (Paths.types/0 / .operations/0 / .defect_reasons/0) instead of rendering a list of its own — see load_data/2's redirect clause.

Admin-chrome pattern: self-wrapping render with LayoutWrapper.app_layout so the active subtab's name/description land in the global admin header (page_title/page_subtitle, see the :self_wrapped_layout on_mount and tab_title/1 / tab_subtitle/1) instead of an in-page header. The Machines / Types / Operations / Defect Reasons switcher is a local tabs tabs-border bar rendered under that header — same look as PhoenixKitWarehouse.Web.Components.WarehouseHeader — in addition to (not instead of) the PhoenixKit admin sidebar's own subtab nav (:manufacturing_machines / :manufacturing_types / :manufacturing_operations / :manufacturing_defect_reasons), same dual-nav shape every other module's parent/subtab pair uses.

Filtering UI

Unlike PhoenixKitWarehouse's list pages, :index does not render a FilterChips-style pill widget per active filter — deliberately, to keep this wave's footprint small (dev_docs/IMPLEMENTATION_PLAN.md M17). Toggling a column's funnel icon in the Columns modal still reveals a plain labeled input for that column (driven by the very same set_filter_value/clear_filter events Web.ColumnManagement injects), but instead of per-chip pill styling with an individual ✕ button, a single "N filters active" indicator plus one "Reset" button clears every filter value at once.

Type-badge staleness window

The handle_info/2 clauses below that refresh :machines on a machine_type broadcast race EntitiesRegistry's own subscription to the same PubSub message: both processes receive the broadcast independently, with no ordering guarantee that the registry's ETS cache has already been invalidated by the time this LiveView's handle_info/2 runs assign_machines/1 and re-resolves type_names via EntitiesRegistry.label/3. If this process's callback wins the race, the re-render can briefly show the pre-change label/title until the next broadcast or navigation. This is accepted as the cost of the pattern — the same trade-off Andi's StatusRegistry-backed live views make — not a bug to fix here. Deliberately not mitigated by making this callback synchronously reload the registry itself: that would couple this LiveView to EntitiesRegistry's internals and reintroduce the N+1 query cost the cache exists to avoid.