Harden fx_reclaim against project closure mid-drain; cache resolved track per item; correct two stale budget comments

src/shell/view/fx_reclaim.h

@@ -31,13 +31,18 @@ inline constexpr double kParkHoldMs = 3000.0;
 // chain and cannot be split, so a budget decides only how many TRACKS a tick moves --
 // and a single track with a long chain overruns it by as much as that chain costs.
 //
-// ONLINE 120ms: onlining restores state the user owns and is waiting on, so a tick
-// buys at least one typical load and two cheap ones. OFFLINE 30ms: under one typical
-// unload, so opportunistic reclaim moves exactly ONE track per tick and yields --
-// background work must not make the UI feel worse than the switch already did. The
-// budget is checked only AFTER a step, never before the first and never mid-step, so
-// a track dearer than the whole budget still runs; that is what makes forward
-// progress unconditional.
+// ONLINE 120ms: onlining restores state the user owns and is waiting on. The check
+// runs only AFTER a step, so against the cited 105ms typical load it admits TWO
+// typical tracks per tick (105 < 120, so a second runs; 210 >= 120 stops a third),
+// not one -- worst case a tick runs over budget by up to one track's whole cost.
+// OFFLINE 30ms: background work must not make the UI feel worse than the switch
+// already did. At the cited 36-42ms costs one track alone already clears the
+// budget, so opportunistic reclaim moves ONE track and yields -- but that count is a
+// property of those costs, not the budget: a cheap chain (a stock JS at ~1ms) stays
+// under 30ms for many tracks in a row and all of them move in one tick. Checked only
+// AFTER a step either way, never before the first and never mid-step, so a track
+// dearer than the whole budget still runs; that is what makes forward progress
+// unconditional.
 inline constexpr double kOnlineBudgetMs  = 120.0;
 inline constexpr double kOfflineBudgetMs = 30.0;