Adopt KnpMenu builders for main, account, and administration navigation

Is your feature request related to a problem? Please describe.

Navigation contains feature flags, permissions, user state, and deployment choices. When those conditions live in Twig templates, they are hard to test in isolation and optional extensions must copy or override global templates. This causes merge friction and makes a small menu addition disproportionately expensive.

Several pages also define Materialize tab navigation directly in Twig. Although these tabs contain fewer visibility decisions, maintaining their markup separately prevents navigation components from following a single, consistent implementation.

Describe the solution you'd like

Adopt versions of KnpMenu and KnpMenuBundle compatible with the 2.7 platform. Define service builders for main navigation, account navigation, administration navigation, and tab navigation. Put visibility decisions in Symfony services so they can be unit-tested and can depend on the authenticated user and enabled capabilities without template logic sprawl.

Migrate all existing Materialize tab navigations as part of the same implementation, including the user configuration, internal settings, about, and how-to pages. Use a shared KNP Twig template for their common Materialize markup while preserving each page's existing tabs, labels, fragment targets, ordering, and behaviour.

Render these menus through KNP Twig helpers/templates while preserving the Materialize markup, accessibility semantics, active-state styling, translations, and responsive behaviour. Publish decoration-friendly concrete service boundaries so an optional bundle can extend and decorate the core builders to append, remove, or reorder its own items without replacing core templates. Dedicated application interfaces are not required for these extension points.

Describe alternatives you've considered

Extra Twig blocks still require global template overrides and do not provide a structured menu tree. A generic plugin framework would be broader than the need: service decoration provides a native Symfony extension mechanism.

Keeping the existing tabs as manually rendered Twig markup would reduce the immediate scope, but would leave two different implementations for equivalent navigation components and duplicate the Materialize tab rendering already introduced by this work.

Additional context

This work should follow the dedicated prerequisite refactoring that replaces JavaScript-only links with semantic buttons throughout the application. The KNP renderers should preserve the resulting distinction between navigational links, meaningful fragment links, and JavaScript action buttons rather than reintroducing fake link destinations.

Suggested acceptance criteria:

• the main, account, administration, and tab menu trees have named builders and documented extension points;
• all existing Materialize tabs on the user configuration, internal settings, about, and how-to pages are rendered through KNP Menu;
• visibility conditions are tested without rendering complete templates;
• rendered menus preserve current routes, meaningful fragment targets, translations, active state, theme, and responsive behaviour;
• rendered controls preserve the semantic distinction between links and buttons established by the prerequisite refactoring;
• a test extension can add one item by extending and decorating a concrete core builder without copying a template;
• no backport to 2.6, where supporting an older KnpMenu line adds maintenance cost without the intended platform alignment.