Batch instance teardown so its instance reads do not scale with the token count

The teardown half of the pre-alpha11 audit's deferred performance work. PERF-3 (the pending-actions scan) split out to #3610809; this issue is now just the teardown batching (PERF-4).

Problem

cancelInstance() and failInstance() mark the instance terminal, then call cancelLiveTokens() to cancel each live token through cancel(). Two things there read the instance table once per token: cancel()'s completion and stall rechecks (checkCompletion() and recoverStalledInstance(), each loading the instance uncached only to early-return, since the instance is already terminal), and cancelChildInstances(), which looks up a token's running subprocess children one token at a time. So tearing an instance with many live branches down issues several instance-table reads per branch.

Fix

• Extract cancel()'s token cascade into a helper. cancel() keeps the completion and stall recheck, since its other callers (a superseded branch, a discriminator join, a timer cancel) run on a still-running instance and need it, but the bulk teardown skips it: every caller of cancelLiveTokens() has already flipped the instance terminal, so the rechecks could only early-return.
• Batch the subprocess-child teardown: cancelLiveTokens() collects the ids of the tokens it cancelled and loads their running children in one parent-token IN query, rather than a lookup per token.
• cancelTimers() loads its pending timer tokens with one loadMultiple() instead of a query per id.

A kernel test tears down a two-branch and a five-branch instance and asserts the instance-table read count is identical, so teardown is O(1) in the branch count, not O(n).

Pre-1.0 and no schema change, so nothing to apply on the live site.