tp: scope critical-path stack work per query

`thread_executing_span_with_slice` previously eagerly built four
whole-trace tables at module load (per-root critical path,
thread_state x flat-slice SPAN_LEFT_JOIN, the CP x slice intersect,
and their joined cross product) plus a SPAN_JOIN over them. Every
consumer already takes a `(root_utid, ts, dur)` window, so this was
~95 s of `INCLUDE PERFETTO MODULE` cost on a 17 MB trace for queries
that scope down to a single window.

Drop the materialisations and the SPAN_JOIN. A new helper
`_critical_path_relevant_spans(root_utid, ts, dur)` reproduces the
same intermediates lazily inside its body: the walk runs only over
wakeup nodes overlapping the window, the SPAN_LEFT_JOINs are queried
with `utid` push-down, and the self x CP intersection is open-coded
(`_interval_intersect!` was tried and was ~40x slower because its
twin evaluation interacts badly with the join-back to recover
columns). `_critical_path_stack` materialises one helper pass to
amortise across its ten UNION-ALL references.

Output is bit-identical (all 82 TablesSched diff tests pass with no
expectation changes).

Per-stage timings on `android_postboot_unlock.pftrace` (17 MB):

  module load             ~95 s -> ~12 s
  narrow stack call       ~0.3 s -> 1.3 s   (no upfront amortisation)
  whole-trace stack call  ~0.3 s -> 2.4 s   (")
  CP-Lite (reference)      0.3 s -> 1.2 s

A single CP-Stack click in a UI workflow is ~60x faster end-to-end
(95.3 s -> 1.6 s); breakeven for scripts is ~100 narrow calls.

Bug: 414534218
Change-Id: I48a79ff17643fa0d9a8ec7083454f2abad249bd4