Bug: FileVarExportHandler silently drops the TTL passed by FileLocatorCached, so the locator cache never expires

### PHP Version

8.5

### CodeIgniter4 Version

4.7.4

### CodeIgniter4 Installation Method

Manual (zip or tar.gz)

### Which operating systems have you tested for this bug?

macOS, Linux

### Which server did you use?

cli

### Environment

production

### Database

Not relevant to this bug.

### What happened?

`FileLocatorCached::saveCache()` passes a 24-hour TTL to the cache handler:

```php
// system/Autoloader/FileLocatorCached.php:75-80 (v4.7.4)
private function saveCache(): void
{
if ($this->cacheUpdated) {
$this->cacheHandler->save($this->cacheKey, $this->cache, 3600 * 24);
}
}
```

But `FileVarExportHandler::save()` declares only two parameters:

```php
// system/Cache/FactoriesCache/FileVarExportHandler.php:20 (v4.7.4)
public function save(string $key, mixed $val): void
```

PHP silently discards an extra argument passed to a non-variadic userland function, so the
TTL never reaches the handler — no error, no warning, no log entry. Nothing about expiry is
written to the cache file, and `get()` is a bare include with no expiry check at all:

```php
// system/Cache/FactoriesCache/FileVarExportHandler.php:53-56 (v4.7.4)
public function get(string $key): mixed
{
return @include $this->path . "/{$key}";
}
```

The result is that the locator cache **never expires**, while the calling code states that it
should expire after 24 hours. A file discovered by the locator — for instance a
`Config/Registrar.php` shipped by a package or added by the application — stays invisible for
as long as the cache file exists on disk, not for the 24 hours the call site intends.

Both files are identical in v4.7.3, v4.7.4 and on the default branch at the time of writing.

### Steps to Reproduce

1. Enable the locator cache: `php spark optimize`, which sets `$locatorCacheEnabled = true`
in `app/Config/Optimize.php`.
2. Run any command or request, so that the cache file is written to
`writable/cache/FactoriesCache_FileLocatorCache`.
3. Open that file. It contains `cacheUpdated = false`, but any locator lookup afterwards in the same process sets
`$this->cacheUpdated = true` again, and `__destruct()` (`:70-73`) then writes the old
in-memory state back to disk. So a "clear the cache, then continue working" sequence inside
one process can end with the stale file restored.

We hit the original bug in a deployment: a `Config/Registrar.php` added to the disk after the
cache had been warmed stayed invisible, and every route protected by the filter aliases it
declares answered HTTP 500. Our workaround is to delete the cache file from a separate
process (a plain `rm -f` in the deploy script) rather than from PHP, which is a workaround
for the second detail above rather than for the missing TTL.

This replaces #10537, opened by the same account and closed automatically by
`mergeable[bot]` because it did not follow this template. It is the same defect, refiled in
the required form: the account cannot reopen the original issue, so this is a new one rather
than a duplicate report.

system/Autoloader/FileLocatorCached.php と system/Cache/FactoriesCache/FileVarExportHandler.php を読み、saveCache()、save()、get()、deleteCache()、__destruct() に注目してください。php spark optimize を実行し、現在の動作を確認するために writable/cache/FactoriesCache_FileLocatorCache を調べてください。呼び出し元とハンドラーがキャッシュの有効期限について一致し、文書化された24時間の動作または明示的に期限切れにならない契約が強制されていれば完了です。

索引モデルが issue の本文から書いたものです。