[6.x] Move nocache views to Statamic temporary storage

[jackmcdade]

What this changes

Statamic generates temporary views for Antlers nocache regions, Blade nocache components, and @antlers blocks. These files were stored alongside Laravel’s compiled views, with two paths writing directly to storage/framework/views.

All three types of generated view now live in storage/statamic/tmp/nocache. This keeps Statamic’s temporary files together in the application’s normal writable storage directory and gives Vite one consistent location to ignore.

The companion change in statamic/statamic#152 updates the default Vite configuration so these generated files do not trigger browser refreshes during npm run dev.

Related to #13158.

Testing

• Added coverage for all three generated view types and their new storage location.
• Static-caching suite: 201 tests, 502 assertions.
• Blade suite: 96 tests, 152 assertions.
• Pint passed.

[jasonvarga]

Review:

• Predictable temp dir in shared /tmp: sys_get_temp_dir().'/statamic-'.md5(base_path()).'/nocache' is deterministic and world-traversable; loses the isolation a project directory's own permissions previously gave on shared hosting, and makeDirectory(..., force: true) won't detect if that path already exists/is owned by someone else.
• Should a package require the system temp dir be writable at all? This adds a writability requirement outside Laravel's normal storage//view.compiled contract — questionable for a container/read-only-rootfs or open_basedir-restricted host.
• May not fix the reported bug: the original issue reproduction is browsing the Assets screen, which doesn't obviously invoke nocache tags at all. The Vite-log evidence tying this to nocache came from a different repro (browsing a CP collection view). Asset thumbnail/attribute caching (Attributes.php, GlideManager.php) writing into the project tree during Assets browsing looks like a better fit for the original report, and isn't touched here.
• Two other code paths have the same bug and aren't fixed: View/Blade/Concerns/CompilesNocache.php and View/Blade/AntlersBladePrecompiler.php also write random/hash-named files into storage/framework/views and can trigger the same reload loop on Blade-templated sites.

tbh I think we should just tell people to ignore storage in their vite configs.

We put our nocache views within storage/framework/views because it'll be a safe spot depending on the server config. If your server requirements need you to move the compiled views somewhere else, you customize view.compiled and ours go along for the ride.

I think a better solution might be:

• Move the nocache files to storage_path('statamic/tmp/nocache') as well as the two missing spots
• Make vite config ignore storage/statamic in statamic/statamic

That'd fix new sites, and for existing sites they could just add the new ignore rule to their existing vite config.

[jackmcdade]

OK, should we open a new PR for that and then close this one?

[jasonvarga]

This PR could probably still just do the Move the nocache files to storage_path('statamic/tmp/nocache') as well as the two missing spots. But yeah lets also address the vite config as a PR on statamic/statamic

[jackmcdade]

Updated this PR to store all three nocache-generated view types in storage/statamic/tmp/nocache. I’ve also opened statamic/statamic#152 to add the matching Vite ignore rule for new projects.