test: #3624694 Count the lookups a page of runs costs, instead of reading listInstances() as text

Two tests read a file the module ships and asserted on its words.

tests/src/Unit/InitiatorLookupCostTest read LocalOrchestraClient.php as a string, cut out the body of listInstances() and asserted it contains toWireNames( and not toWireName(. Renaming either method, or resolving the page through a helper, failed it while the behavior it guards was untouched; and a per-row lookup routed through a differently named method passed it.

What it stood in for now lives in LocalOrchestraClientTest, which drives the client: five runs started by five different people, the page listed one at a time and then all at once, and the account queries each costs counted with the entity cache emptied first so a load really reaches the database. One lookup for the page is the same number both times. Mutated to name each row separately, it is 2 against 10.

ViewsMenuLinksTest::testTheReadmeNamesThePagesThisModuleShips asserted that the README's prose contains each shipped view path. A README is prose, and a stale README is fixed in the README, so it is deleted. It is accurate today: the four dashboard paths it names, plus /orchestra/my-requests, are what this module ships.

---

Rebased on 1.x after !532 (merged) merged (clean, no overlap).

Audit rounds (5, closed on a clean round). Mutation is the only real instrument here, since this MR changes no source file and the test-only changes lane therefore proves nothing about it (see the note above).

Round 2 mutated the client: naming each row separately fails the new test 2 against 10, and making the lookup free trips the non-zero premise at 0 is greater than 0. Then a third mutation removed the helper's cache.entity->deleteAll() — and the defect was still caught.

It turns out that call was the same call twice. ContentEntityStorageBase::resetCache() asked for no ids in particular empties its own memory cache and then deleteAll()s the persistent entity bin, which is cache.entity for this storage. So the line did nothing, and its comment ("both caches") taught the reader something untrue about core. Removed, with the comment corrected to what core actually does.

Round 3 put the same question to the two setup lines, and both are load-bearing: dropping either installEntitySchema('user') or 'user' from $modules errors the test, because a kernel test's enableModules() resolves no dependencies of its own — orchestra_api declaring drupal:user does not enable it. That also shows the naming path had no kernel coverage in this class at all before, which is what left a source-grep as its only guard.

The README the deleted assertion guarded was checked against the shipped view configs one last time: it names exactly the five paths this module ships, no more and no fewer.