Issue #3622168: A stand-in's task list is cached across the cover being granted, withdrawn or lapsing

The Actionable by the current user filter narrows a list through the viewer's standing delegations, which are granted, withdrawn and dated, and declared none of that: a rendered task list was cached permanently with no delegation tag.

• The filter uses AssignmentCacheTrait and applies the viewer's assignment cacheability from query(), where it has already asked the matcher the two questions the row set rests on. A cached list now carries orchestra_delegation_list and expires at the next moment any cover it consulted starts or ends.
• AssignmentMatcher::calculateCacheableMetadata() consults the account's own cover before reporting what a verdict about them rests on. The resolver reports a dated bound only for the delegations some question actually read, so a caller that declared before asking was told the answer never expires, and one that declared after a question about somebody else was told when that other person's cover lapses.

The Views results cache is unaffected: its key is built from the query text and its arguments, and the delegator ids and viewer tokens are bound as arguments.

Kernel coverage on the shipped view with no assignment-aware column added, so the filter alone is measured.

Closes #3622168.

---

Audit round on this MR (five passes over the diff):

• The test asserted the tag only for a viewer who already has cover, so the half of the finding about granted cover was unpinned: a stand-in covering for nobody yet is exactly the page that must carry orchestra_delegation_list. Both viewers are now asserted, as two accounts rather than two reads of one, because the resolver answers each account once per request.
• AssignmentMatcher::calculateCacheableMetadata() claimed the extra question "pays nothing". It costs one indexed read of that account's delegations per request, and none at all where orchestra_delegation is absent - stated rather than glossed.
• The filter's comment justified itself by the order of the calls around it, which stopped being load-bearing once the matcher asks for itself.
• AssignmentCacheTrait described "four Views field handlers" and two kinds of host; it now has three, and the filter applies the rule from query() because it has no preRender().
• Test prose used gendered pronouns for the fixture accounts, which the Drupal sniff rejects.