moves step to enable addons as first in the list from enableAllOptions

[hanna-meda]

Description

Fixes #364

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

The export/import scenario “Should not change enabled fields with update” could fail due to value format mismatches between versions (for example empty string/"1" versus 0/1 after update and re-save).
This PR moves the step that enables add-ons to the beginning of the sequence in enableAllOptions. This ensures that settings are re-saved at least once via the Save button after toggling the add-ons, thereby eliminating any value format mismatches between versions.

What was tested

Ran npm run test:export five consecutive times.
Result: all tests passed in every run.

How to test

Run npm run test:export and verify that:

1. The scenario “Should not change enabled fields with update” passes consistently.
2. Export comparison between data 51 and 52 no longer reports false negatives caused by format normalization.

Affected Features & Quality Assurance Scope

Only the "enableAllOptions" in page-utils.ts, moved

wp-rocket-e2e/utils/page-utils.ts

Line 571 in 2d8fce7

if(await this.sections.doesSectionExist('addons')) {

to the beginning of the sequence.

Technical description

Moved "enableAllOptions" in page-utils.ts to the beginning of the sequence.

Documentation

No documentation update required (test scenario adjustment only).

New dependencies

N/A

Risks

N/A

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

N/A

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[hanna-meda]