[6.x] Avoid loading the revisions store when finding a working copy

[jasonvarga]

Summary

Resolving a single working copy via Revisions::findWorkingCopyByKey() ran a query against the revisions Stache store:

return $this->query()
    ->where('key', $key)
    ->where('action', 'working')
    ->first();

The first such call forces the revisions store's indexes to build, which loads every revision and working-copy file on the site into memory. A working copy is a single file at a deterministic path, so this reads it directly instead:

$path = $this->directory().'/'.$key.'/working.yaml';

if (! File::exists($path)) {
    return null;
}

return $this->store->makeItemFromFile($path, File::get($path));

This restores the pre-#10437 behaviour for this lookup while keeping the query builder for actual revision queries (whereKey(), CP revision history, etc.).

Why

Entry::workingCopy() / hasWorkingCopy() are called per-entry during Stache warming — e.g. via computed fields, or any values() call during URI index building. Before #10437 each call was a cheap file_exists(); afterwards each call could trigger a full warm of the revisions store.

On a real site (~3,600 entries in one collection, revisions enabled) this was the dominant cost of stache:warm. Isolated cold-load of that collection:

findWorkingCopyByKey	time	peak memory
query builder (current)	144s	2,224 MB
direct file read (this PR)	15s	728 MB

Fixes #14842.

Testing

Added coverage to tests/Revisions/RepositoryTest.php:

• finds a working copy by key
• returns null when there's no working copy
• does not use the query builder (regression guard against re-loading the whole store)