Adapt the UI tests for the Stores back office page

Goal Update the UI tests for the legacy controller on the newly migrated BO page so that the feature flag is stable.

Side goal

This is one of the first issues related to UI tests done without the QA team. So we thought it's an opportunity to improve the tools at our disposal, especially some AI contexts explaining:

• how the UI tests behave in the core, and what the responsibility of the core is (supposed to be pure scenarios that drive components from the UI testing library)
• explain how the ui-testing-library is architecture, how each page has a component, and what should be in the interfaces of each page
• the interfaces so far are often very specific to get some elements from the page (including the form pages), maybe we'd need some more generic ways to get elements when we want to check form content. The problem is that the selectors are supposed to be in the library only, so it may be against the usual split of responsibility. Maybe some generic getters based on the form name (ex= product[details][name] would be acceptable to use from the core?
• The UI testing library has a system of extensions for all the pages that are split by version; the default location is the develop folder. When a sub-version needs different selectors, a new page is created that is mostly here to adapt the selectors
• it means when a page is migrated, the develop selectors must be updated, while the old ones need to be backported into a sub-version page
• the library can be modified locally and built and force-replaced in a local environment, using a make command. This should be documented for developers (already a short explanation in the README can be improved), and also for the AI agents so they know how to work and iterate locally
• the core should also contain some details about the UI tests; some context should be in the core, some in the library. The context should not duplicate their respective content. Rather, the library will probably have no reference to the core, being described mostly as a standalone tool. However, the core could reference some of the contexts present in the library (to avoid duplication)
• the context files should be completed with skills that can be reused. The skills should be usable in different contexts:
  • fixing existing tests
  • creating new scenarios for an existing page
  • creating a new component for a completely new page
  • handling the migration legacy-to-Symfony of a page
  • ... (more to be defined and thought out while working on this)

Here are a few PRs of pages that were migrated and whose tests were adapted; they can be analyzed and used as a reference, especially if we decide to create a skill that helps with finalizing the migration of a page (most of them have related PRs on the ui testing library that also should be analyzed for reference):

• https://github.com/PrestaShop/PrestaShop/pull/41594
• https://github.com/PrestaShop/PrestaShop/pull/41777
• https://github.com/PrestaShop/PrestaShop/pull/41630
• https://github.com/PrestaShop/PrestaShop/pull/41627
• https://github.com/PrestaShop/PrestaShop/pull/40238
• https://github.com/PrestaShop/PrestaShop/pull/39516