[6.x] Reset memoized Stache state between jobs instead of disabling it process-wide

[edalzell]

Cause

Statamic::isWorker() disables in-process memoization for the entire life of a queue worker process whenever the running command is queue:*/horizon:*, instead of just resetting that memoization between jobs. That means every single access within one job falls back to a cache-store round trip (or full disk listing) rather than reusing an already-computed value, making queued indexing dramatically slower per document than running the identical work synchronously.

Closes #15118.

Approach

• Store/ContainerAssetsStore/Index are container singletons that persist for the whole worker process, so they genuinely need an explicit reset at job boundaries. Added a resetMemoizedState() method to each, invoked once per job via a new JobProcessing listener that's only active when Statamic::isWorker() is true (so synchronous dispatch is completely unaffected).
• AssetContainer/AssetContainerContents are Blink-facade-backed, and Laravel's real queue:work daemon loop already clears resolved facade instances before every job it processes — so their isWorker() gates were redundant (and actively harmful, since they disabled memoization within a job too) and were simply removed.
• A redundant eager cache-store write in AssetContainerContents::add() (made unnecessary by the caller always chaining ->save() right after) was also removed.

Real performance numbers

Measured on a sandbox app with a 17,000-file asset container, indexing a 100-entry chunk (chunk_size 100) where each entry references 4 assets:

	per 100-doc job
Sync (QUEUE_CONNECTION=sync)	~29ms/doc (2.9s total)
Queue worker, before this fix	~2.0s/doc (3m 20s total)
Queue worker, after this fix	~10ms/doc (1s total)

That's a ~200x speedup for the identical job, with the fixed worker now on par with (slightly faster than) sync — confirming the fix removes the bug's overhead without reintroducing cross-job staleness (covered by new tests around resetMemoizedState()).