Add test coverage for forward navigation, progress bar classes and error logging

Problem/Motivation

The existing tests cover the settings form, config schema, update 8002 and a page load smoke test. The behavior users rely on has little or no coverage: forward navigation through the progress bar, errors shown again when a page is revisited, the progress bar classes, prevent_next_validation, and the error and page visit logging. Without these, changes such as #3632737 are hard to review, and sites that depend on the markup (for example the has-errors and is-complete classes) can break without notice.

Proposed resolution

Add tests in this order, each as its own MR or alongside the issue that changes that area.

Functional

• Forward navigation: with forward_navigation on, every page link in the progress bar can be used, moving ahead skips validation, and returning to a page shows its logged errors (WebformNavigationHandler::alterForm(), submitForm()).
• Progress bar and tracker classes: has-errors, is-complete and the current page class from webformnavigation_preprocess_webform_progress_tracker() and webformnavigation_preprocess_webform_progress_bar().
• prevent_next_validation: Next with an empty required field moves on when enabled, and stays on the page when disabled.
• Final submit: started in #3632737 (ValidateAllPagesTest).

Kernel

• WebformNavigationHelper:
  • logPageVisit() does not log a page twice.
  • getErrors() returns the errors for one page or all pages.
  • logPageErrors() maps nested element errors (parent][child) to the element's page.
  • Errors for a submission that is not saved yet are stashed, then logged by postSave() through logStashedPageErrors().
• webformnavigation_webform_presave(): enabling forward navigation sets draft, purge, purge_days and wizard_progress_link. Record the current behavior before it changes.
• Log cleanup: deleting a submission removes its webformnavigation_log rows (postDelete()).

Remaining tasks

• Write the tests above.
• Decide what to do with the additional_error_message setting. It is saved and has a schema, but nothing reads it, so it never appears in the final submit error. Either use it (with a test) or deprecate it, in a separate issue.

User interface changes

None.

API changes

None.

Data model changes

None.