Ensembles 3.0.8

• Fix a stale CloudKit listing cache hiding cloud files from a device indefinitely. The CloudKit backend keeps a cache of the zone listing between launches so it can fetch changes incrementally. That cache was stored in the system caches directory under a name derived only from the zone, which gave it a lifetime independent of the event store it describes: it survived removal of the event store, removal and recreation of the CloudKit zone, and app deletion. On the next launch the backend resumed an incremental fetch using a change token minted against the old zone, and CloudKit reported only what had changed since that token — files predating it were never mentioned again. A device could therefore download data files while never being told about the baseline that referenced them, then sit with an empty store, no pending work, and no error to report, because from its point of view the cloud held nothing else. The cache now lives inside the event store's directory, so removing or rebuilding the store removes the cache with it, and two stores on one device no longer share one cache. Any cache found in the old location is discarded rather than adopted: nothing in those files records which store or which incarnation of the zone they belong to, so a stale one cannot be told apart from a sound one, and carrying the change token forward is precisely what caused the problem. Upgrading therefore costs one full listing refetch per device on the first launch. That fetch asks for file metadata only, so no file contents are re-downloaded. Backends that persist remote state can adopt the same guarantee through the new CloudFileSystemSetup.setLocalStoreDirectory(_:) hook, which has a default no-op implementation and so is source-compatible. Reported by Keith, who captured the evidence that identified it: his device's cache still listed a store registration belonging to its own pre-deletion incarnation.