CLI: `freecadcmd -c` crashes with "filesystem error: status: File name too long" when `FreeCADGui.showMainWindow()` is called and the script text has no `/` in its first ~255 bytes

### Problem description

## Environment

- FreeCAD version: 1.1.3 (`['1', '1', '3', '20260725 (Git shallow)', 'Unknown', '2026/07/25 04:52:02', 'grafted,grafted', '145529fe741292ff0b3977a01195bf0247425794']`)
- Distribution: official `FreeCAD_1.1.3-Linux-x86_64-py311.AppImage`
- OS: Ubuntu 24.04.4 LTS (noble), x86_64
- Running under `xvfb-run` (no physical display), `freecadcmd` executable

## Summary

When `freecadcmd` is invoked with `-c ""` and the script calls `FreeCADGui.showMainWindow()` to start an offscreen GUI session (a documented technique for headless thumbnail/screenshot generation), the whole process crashes with an uncaught `filesystem_error` if the script text has no `/` character within roughly the first 255 bytes. The crash message includes the *entire raw script text* as the "path" that failed `stat()`, which strongly suggests something in the startup path (possibly `Application::processFiles`, which already does path canonicalization on command-line arguments, see #27174) is treating the `-c` argument's raw text as a candidate file path to open, rather than only the code passed for execution.

This is a hard crash (no Python exception is raised inside the running script — the whole `freecadcmd` process exits), so it can't be caught or worked around from the script side.

### Workbench affected?

None

### Steps to reproduce

## Minimal reproduction

```bash
python3 -c "
comment = '# ' + ('x' * 260)
script = comment + chr(10) + 'import FreeCADGui' + chr(10) + 'FreeCADGui.showMainWindow()' + chr(10) + 'print(\"reached\")'
open('/tmp/repro.py', 'w').write(script)
"
xvfb-run -a freecadcmd -c "$(cat /tmp/repro.py)"
```

i.e. the script is just:

```python
# xxxxxxxxxxxxxxxxxxxxxxxxxxxxx...(260 x's, no '/' anywhere)...xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
import FreeCADGui
FreeCADGui.showMainWindow()
print("reached")
```

### Expected behavior

### Expected result

The script should execute normally and print `reached`, exactly as it does when the leading comment is shortened (e.g. 50 `x`s instead of 260) — confirmed working in that case.

### Actual behavior

### Actual result

```
Application unexpectedly terminated: filesystem error: status: File name too long [# xxxxx...(the entire script text, verbatim)...print("reached")]
```

The process exits; `print("reached")` never runs.

### Development version About Info (in Safe Mode)

```shell
## Notes

- The trigger is **not** related to CJK/non-ASCII text, quoting, or any particular content — pure byte length of a slash-free run of characters. A comment, a docstring, a long variable name, or any other text works equally well/badly as the trigger.
- If the same slash-free run of text is broken up by inserting even a single `/` character before the 255-byte mark, the crash does not occur — consistent with a single-path-component length check (`NAME_MAX`, 255 bytes on ext4/most Linux filesystems) being triggered against the raw script string as if it were one path component.
- Without `FreeCADGui.showMainWindow()`, the same long-comment script runs fine under plain `freecadcmd -c` — the crash only appears once a Gui session is started this way, which points at Gui/Start-workbench startup code (rather than core script execution) doing something with the raw CLI arguments.
- Workaround: write the script to a file and pass a short wrapper instead of the raw script, e.g. `freecadcmd -c "exec(open('/path/to/script.py').read())"`, since that keeps the `-c` argument itself short.

Happy to provide more detail or test a patch if useful.
```

### Last known good version (optional)

```shell

```

Reproduce the failure with the provided xvfb-run and freecadcmd -c command, then trace Application::processFiles and the GUI startup path reached by FreeCADGui.showMainWindow(). Compare behavior with a shortened comment and with the documented wrapper workaround. Done means the long slash-free script runs without process termination and prints "reached".

Written by the indexing model from the issue text.