turbo-tasks-backend: simplify the collectibility predicate and collect transient tasks - #98615

…t transient tasks

Two dependency sets were pinning tasks that nothing actually reaches:

- `cell_dependents` / `cell_dependents_hashed` are redundant with ancestry. A
  cell dependent is either a child, whose child edge already orders the
  teardown, or a sibling reached by passing a `ResolvedVc` laterally, which
  needs a common ancestor that collects both in the same pass. Counting them
  deadlocked the cycle `NftJsonAsset::content` ->
  `all_assets_from_entries_filtered`, whose tasks could then never be collected.
- `output_dependent` is redundant with `parent_count`. It records a read of a
  task's *output* -- the `OperationVc` representation -- and those reads go
  through `connect()`, so the reader is already a child.

With both gone the whole `Data`-category condition goes too, so the predicate
reads only `Meta`: the cheap shard scan and the authoritative under-guard
recheck now get the same answer, rather than the scan being a pre-filter.

Also drops the persistent-only filter in `gc_scan_shard`. Transient tasks are
session-scoped, but a session can be long, so leaving them uncollected retains
whole subgraphs for the life of the process. This was previously blocked by two
failures, both of which are stale references that the preceding commit makes
non-fatal: a `MustExist` panic when an invalidator named a collected task, and a
`Delete` snapshot item for a task with no task type.

`dispose_root_task_releases_anchored_subgraph` now expects two collections
rather than one: the disposed root is itself transient, so releasing the last
reference to the subgraph reclaims the root along with its leaf.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>