opcache_invalidate is not safe under high concurrencies

Nobody has claimed this yet.

### Volt Version

1.7.1

### Laravel Version

12.10.2

### PHP Version

8.4.7

### Database Driver & Version

_No response_

### Description

This issue is specifically about this line in Volt. It would be nice if it can be avoided in productive environments: https://github.com/livewire/volt/blob/0ab9d34c53f87444017270a2178250a19f3083ec/src/ComponentFactory.php#L35

This was first raised in the [FrankenPHP Repo](https://github.com/dunglas/frankenphp/issues/1530), where @robsontenorio noticed that when stress testing, the application would end up in a memory corruption after a while.

This happens due to `opcache_invalidate()` being called each request leading to a buildup in memory that eventually leads to an `opcache_reset()`.

`opcache_reset()` is currently not really safe under concurrency (both in [FPM](https://github.com/php/php-src/issues/14471) and [FrankenPHP](https://github.com/php/php-src/issues/18517), so I'd recommend avoiding an `opcache_reset` if possible in production environments.

Also when testing with the [reproducer](https://github.com/robsontenorio/paper.mary-ui.com/tree/franken-bug), I noticed that the path passed to `opcache_invalidate` was that of a Blade file (which makes it look unitended)

### Steps To Reproduce

You can use the reproducer provided by @robsontenorio https://github.com/robsontenorio/paper.mary-ui.com/tree/franken-bug

It will take a while for the corruption to appear, using postgres/mysql instead of sqlite will make it happen faster.

Inspect src/ComponentFactory.php at line 35 and review the linked FrankenPHP issue and reproducer to understand how opcache_invalidate is called during requests. Stress-test the reproducer, including with PostgreSQL or MySQL, and verify that the resulting behavior no longer causes unsafe opcache resets or memory corruption under high concurrency.

Written by the indexing model from the issue text.