Fix DeepCompile ZeRO-3 gathered parameter ownership

[tohtana]

Problem

DeepCompile's ZeRO-3 eager fallback could gather a partitioned parameter while Dynamo was only evaluating guards, carry an unowned full parameter into a later forward, or keep tracking a parameter after an explicit GatheredParameters context had adopted it. Those paths gave the fallback and user code conflicting responsibility for the same gathered lifetime.

Why it matters

Guard evaluation must not change parameter residency. At each forward boundary, a nonpersistent full parameter must be partitioned unless an explicit user context owns it, and exactly one owner must decide when it is safe to release.

Solution

This change suppresses eager fallback gathers during Dynamo guard evaluation, releases unowned available parameters before the next outermost forward, and records one fallback owner per gathered parameter. Entering GatheredParameters transfers ownership to the user context, including nested and exceptional exits, so the fallback cannot repartition user-owned storage. This branch is the stack base and does not change compiler-global lifecycle or scheduler policy.