…ario

…en I add` - Promotion & Some other scenarios (#17818)

| Q               | A
|-----------------|-----
| Branch?         | 2.0 <!-- see the comment below -->
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations? | no <!-- don't forget to update the UPGRADE-*.md file
-->
| License         | MIT

Continuation of:
- #17785
- #17782
- #17783

Until now, the checkout-related scenarios have been set up as follows:
• UI – via web actions (e.g. `Given I have a product ...` actually
triggered browser actions to prepare the initial step),
	•	API – a mix of messenger commands and API calls.

During the development of Sylius 2.0, with the introduction of dynamic
components, all scenarios involving product-related actions had to be
marked as JS to work correctly. This significantly increased build time
and reduced overall stability.

This PR focuses on decoupling the Behat architecture to unify the test
setup for both UI and API. The goal is to eliminate most JS tags, which
should lead to greater stability. Some performance improvements are
already noticeable.


This PR doesn’t yet include all refactored scenarios, but at this stage
we already observe the following performance gains:
• For non-JS scenarios, the timing is likely similar — some JS scenarios
have been converted to non-JS, but at the same time, we benefit from
faster setup thanks to the refactor (using messenger commands instead of
API calls or UI interactions to prepare tests).
• For JS scenarios executed via Chromedriver, the same applies — some
Panther scenarios have been switched to Chromedriver, and performance
remains comparable.

JS with Panther: **~30 min → ~20 min**

| Q               | A
|-----------------|-----
| Branch?         | 2.0
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Related tickets | n/a
| License         | MIT

| Q               | A
|-----------------|-----
| Branch?         | 2.0
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Related tickets | continuation of #17818 and #17819
| License         | MIT

<!--
 - Bug fixes must be submitted against the 1.14 or 2.0 branch
 - Features and deprecations must be submitted against the 2.1 branch
 - Make sure that the correct base branch is set

To be sure you are not breaking any Backward Compatibilities, check the
documentation:

https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html
-->

| Q               | A
|-----------------|-----
| Branch?         | 2.0
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Related tickets | #17819
| License         | MIT

This PR has been generated automatically.
For more details see
[refactor.yaml](/Sylius/Sylius/blob/1.12/.github/workflows/refactor.yaml).

…eeds stock

| Q               | A
|-----------------|-----
| Branch?         | 2.0 <!-- see the comment below -->
| Bug fix?        | yes
| New feature?    | no
| BC breaks?      | no
| Deprecations? | no<!-- don't forget to update the UPGRADE-*.md file
-->
| License         | MIT

For some reason, our CI suddenly started failing. It turned out that
there was a small flaw in our UI flow, which this PR addresses.

As part of this proposal, due to the current logic on the offer
page—specifically the dynamic validation of the `Add to cart`
button—some scenarios that rely on this behavior would ideally need to
be rewritten. To avoid that, I introduced a single test that verifies
the actual UI behavior while leaving the remaining tests untouched.

Additionally, I introduced a new ui subpath intended to contain only
pure UI tests. In the future, the plan is to isolate only the most
crucial, individual UI-related cases there while refactoring the
remaining variations into more domain-focused tests.

I’m aware that this approach breaks the BDD principle of specifying
behavior rather than relying on visible UI elements in the scenario
definition; however, since we have some pure UI cases, in my opinion it
is acceptable to use it in such a way.