Migrate GroupEvent from Material UI TextField to native HTML input

[Bouh]

This change simplifies the GroupEvent component by replacing the Material UI TextField with a native HTML input element, mainly to avoid the visual offset when in edit mode compared to the display mode.
This native input approach is inspired from the CommentEvent that is working perfectly.

Changes:

• Replace TextField with native element
• Update event handling to use native onChange and onKeyDown
• Adjust CSS styling to ensure proper alignment between edit and display modes
• Update Material UI input CSS rules for better consistency

---

I did a review with this prompt based on previous reviews:

**English translation:**

Assume the role of the maintainer of the GDevelop codebase.

You are doing a code review; you must examine the code that has changed in this branch.
You need to pay close attention to the order of execution of the code and its implications.

And to these points of vigilance:

* **Never precompute a state before a mutation** → Always compute **AFTER** the action has been performed, using the real data at that moment.
* **Be careful with memoization on mutable data** → This can create race conditions / desynchronization.
* **Throttle repeated user actions** (movement, scrolling) → Otherwise things go too fast and it can crash or become unusable.
* **Always handle edge cases for indices** → `Math.min(index, length - 1)` to avoid out-of-bounds memory access.
* **Self-explanatory code + JSDoc/Doxygen for public functions** → The code should be understandable on its own, but public functions require formal documentation (JSDoc in JS/TS, Doxygen in C++) to generate docs.
* **Internationalization (i18n)** → Any user-visible text must be wrapped in `t()` or `<Trans>` to allow translation.
* **Performance: minimize expensive operations** → Aim for the lowest possible computation time and complexity.
* **Process directly rather than collect then process** → If data is collected only to be processed immediately afterward, it’s better to process it as you go.
* **Avoid O(n²)** → Red flags: a function called frequently (every frame), processing a growing array, performance degrading over time.
* **Incremental Programming** → When data accumulates, process only the delta (new data), not everything again each time.
* **Memoization / Caching** → Store intermediate results to avoid recomputation. The cache can be attached directly to the data (e.g. `data._cachedResult`).
* **Cache Invalidation** → Always detect when the cache is no longer valid (e.g. if `processedCount > array.length` → the data has been reset → reset the cache).
* **Lifecycle-Aware Caching** → Attach the cache to an object whose lifecycle matches the cache’s scope, so it is automatically cleaned up without manual cleanup.
Event listeners management → Any event listener that is added must be properly removed at the appropriate time (e.g. on unmount / disposal) to prevent memory leaks, duplicated handlers, or unexpected behavior.