Refactor the user configuration area into dedicated routes and controllers

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

The user configuration area is currently implemented as a single large controller and a monolithic template containing several independent sections, forms, and workflows.

These sections are coupled through a single /config page and fragment-based tabs. This makes the configuration area harder to maintain, test, extend, and navigate independently. Changes to one section can also require touching code and tests shared with unrelated configuration features.

Describe the solution you'd like

Refactor the user configuration area into cohesive, route-based sections grouped by functional responsibility.

Each configuration section should have:

• a dedicated URL under the /config prefix;
• a focused controller responsible for its functional area;
• dedicated Twig templates;
• independent form handling and validation;
• clear server-side navigation and active-state handling;
• focused functional tests matching the new structure.

The refactoring should cover the existing configuration areas, including general settings, feeds, profile information, password management, two-factor authentication, tagging rules, ignored-origin rules, data reset actions, and account deletion.

The main /config URL should remain the entry point for general settings. Related actions and commands should be reorganized under consistent configuration URLs.

The current Materialize visual styling should be preserved where possible, but the configuration navigation should become regular server-side navigation rather than a JavaScript tab component.

Existing features, translations, ordering, permissions, validation rules, and user-visible behavior should be preserved.

Describe alternatives you've considered

Keeping the current single-page structure and changing only the tab navigation would leave the underlying controller, template, form-handling, and testing complexity unchanged.

Splitting only the controller or only the template would move code around without fully removing the coupling between unrelated configuration sections.

Maintaining compatibility code for the existing #setN fragments was also considered, but does not appear justified. Existing internal links and redirects can be updated to target the new routes directly.

Additional context

The refactoring should include a complete reorganization of the related functional tests so that they follow the new controller and route structure.

Small route-handling and entity-loading inconsistencies exposed by the current implementation should also be corrected as part of the refactoring.

This issue should focus on restructuring the existing configuration area without introducing unrelated navigation libraries or changing its functional scope.