Exporting a project that contains GDScript errors exits with a zero (success) exit code

- *Related to https://github.com/godotengine/godot/issues/91527,
https://github.com/godotengine/godot/issues/94957,
and https://github.com/godotengine/godot/issues/122153.*

### Tested versions

- Reproducible in: 4.5.stable, 4.6.stable, 4.7.stable, 4.8.dev 4e8c061c9

### System information

Godot v4.8.dev (4e8c061c9) - Fedora Linux 44 (KDE Plasma Desktop Edition) on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 5090 (nvidia; 610.43.03) - AMD Ryzen 9 9950X3D 16-Core Processor (32 threads) - 62.33 GiB memory - PulseAudio (44100 Hz, Stereo/mono)

### Issue description

Exporting a project that contains GDScript errors exits with a zero (success) exit code. For example, running this command:

```
godot --headless --export-pack "Linux" /tmp/out.pck --path path/to/test_script_error
```

First export (or after removing `.godot/` to force resource reimporting):

```
[ 0% ] first_scan_filesystem | Started Project initialization (5 steps)
[ 16% ] first_scan_filesystem | Loading global class names...
[ 33% ] first_scan_filesystem | Verifying GDExtensions...
[ 50% ] first_scan_filesystem | Creating autoload scripts...
[ 66% ] first_scan_filesystem | Initializing plugins...
[ 83% ] first_scan_filesystem | Starting file scan...
[ DONE ] first_scan_filesystem

[ 0% ] savepack | Started Packing (102 steps)
[ 1% ] savepack | Storing File: res://control.gdc
SCRIPT ERROR: Parse Error: Expected end of statement after expression, found "Identifier" instead.
at: GDScript::reload (res://control.gd:4)
ERROR: Failed to load script "res://control.gd" with error "Parse error".
at: load (modules/gdscript/gdscript_resource_format.cpp:50)
[ 50% ] savepack | Storing File: res://.godot/exported/133200997/export-e66311c87c39ec8c25379305b5ae724b-control.scn
[ 50% ] savepack | Storing File: res://control.gd.remap
[ 50% ] savepack | Storing File: res://control.tscn.remap
[ 50% ] savepack | Storing File: res://.godot/global_script_class_cache.cfg
[ 50% ] savepack | Storing File: res://.godot/uid_cache.bin
[ 50% ] savepack | Storing File: res://project.binary
[ DONE ] savepack
```

Subsequent exports:

```
[ 0% ] first_scan_filesystem | Started Project initialization (5 steps)
[ 0% ] first_scan_filesystem | Scanning file structure...
[ 16% ] first_scan_filesystem | Loading global class names...
[ 33% ] first_scan_filesystem | Verifying GDExtensions...
[ 50% ] first_scan_filesystem | Creating autoload scripts...
[ 66% ] first_scan_filesystem | Initializing plugins...
[ 83% ] first_scan_filesystem | Starting file scan...
[ DONE ] first_scan_filesystem

[ 0% ] savepack | Started Packing (102 steps)
[ 1% ] savepack | Storing File: res://control.gdc
[ 50% ] savepack | Storing File: res://.godot/exported/133200997/export-e66311c87c39ec8c25379305b5ae724b-control.scn
[ 50% ] savepack | Storing File: res://control.gd.remap
[ 50% ] savepack | Storing File: res://control.tscn.remap
[ 50% ] savepack | Storing File: res://.godot/global_script_class_cache.cfg
[ 50% ] savepack | Storing File: res://.godot/uid_cache.bin
[ 50% ] savepack | Storing File: res://project.binary
[ DONE ] savepack
```

Both cases exit with a zero exit code and still create a PCK, which means CI doesn't catch those issues. Instead, it should exit with a non-zero exit code (preferably a dedicated exit code so it can be distinguished from other engine issues).

It seems the script export mode (text, tokenized, compressed) does not affect this behavior.

### Steps to reproduce

- Export a project that contains at least one script error.

### Minimal reproduction project (MRP)

[test_script_error.zip](https://github.com/user-attachments/files/30794875/test_script_error.zip)

The same project with no errors (for comparison): [test_no_script_error.zip](https://github.com/user-attachments/files/30794877/test_no_script_error.zip)

Start with the headless `--export-pack` command and the provided `test_script_error.zip`, comparing its exit status with `test_no_script_error.zip`. Trace the export path that reports the GDScript parse error; done means erroneous projects return a non-zero status while the clean comparison still exports successfully.

Written by the indexing model from the issue text.