feat: Diagnostic Report Enhancements

[malec-palec]

Goal

Improve the mechanism for detecting errors in the GDevelop project.

Problem

In large projects with multiple people involved, it becomes difficult to spot errors in the EventSheet - especially those that are not covered by the current Diagnostic Report implementation but are still highlighted in red within the EventSheet.

Solution

Enhance the Diagnostic Report with:

Features

• Press F7 to open diagnostic report at any time
• Scans project for missing actions/conditions/expressions from extensions
• Scans project for invalid parameters (shown with red underline in Events Sheet)
• Click on error location to navigate directly to the event
• Event is highlighted for 3 seconds after navigation (like search results)
• Works for both scene events and external events

UI Improvements

• Two-column layout: Location + Instruction
• Action/Condition shown in bold at the beginning
• Long text truncated with "..."
• Click on text or arrow button to expand/collapse
• Arrow button only appears when text is truncated

Preferences

• New option: "Block preview and export when diagnostic errors are found"
• Disabled by default
• Shows alert with error count and F7 hint when blocking

Tests & Documentation

• Unit tests for validation scanner
• Storybook stories for dialog
• New documentation page

This is how the updated Diagnostic Report looks:

[4ian]

Thanks for starting this, we will review it once you remove the draft status :)

[4ian]

Thanks for this PR.
I've added a few comments. Some are nitpickings, but the most important is probably around implementation of the checks: let's try to either have them in C++ or, maybe better, keep them in JS but take advantage of the ReadOnlyArbitraryEventsWorkerWithContext or ReadOnlyArbitraryEventsWorker or AbstractArbitraryEventsWorker to try to subclass it in JS.

Subclassing in JS is a bit cumbersome but I think it's worth trying!

[malec-palec]

Hey @4ian,
I refactored the diagnostic report event validation scanner to rely on the C++ ReadOnlyArbitraryEventsWorkerWithContext instead of manually walking events in JavaScript.

The scanner now delegates all event and instruction traversal to the C++ worker, so future event types will be supported automatically without changes on the JS side.

Local variable scoping is now handled correctly by the worker. As it traverses nested events, it updates ProjectScopedContainers, pushing local variables when entering an event and popping them when leaving. The current scoped containers are passed into the JS validation callback, so validations see the correct set of local variables at each level.

Because the C++ worker does not expose event indices, I precompute a map from event pointers to their logical paths before traversal. During validation, the current event's path is resolved from this map and attached to validation errors, so navigation remains accurate.

While doing this, I also fixed a bug in AbstractReadOnlyArbitraryEventsWorker where sub-events were visited after VisitEvent returned, which caused local variables to go out of scope too early. Sub-events are now visited inside VisitEvent, aligning the behavior with the non-readonly worker and fixing the scoping issue.

Please, take a look.

[4ian]

Thank you for this update, we'll take a look 👍

[4ian]

Added a few comments. While I'm a bit sad that we can't have all the validations grouped somewhere (some are in C++, some in JS, even if you factored some stuff to use the C++ event walker), I think it should work for now!

In the future we will probably want to consolidate this.
Also check if you can solve the conflict and then it should be good to go.

[4ian]

Thanks! Planning to merge this after the release of ~today.