fix: [AI] fix unknown invalidators

[AayushSabharwal]

This removes cases of

unknown nothing invalidated:

I pointed Claude at the problem with a reproducer and it came up with these changes. I don't know how SnoopCompile works, so I can't comment if the changes are valid or not and would really appreciate a review.

This is the explanation Claude gave:

  Root Cause

  The "unknown nothing invalidated" entries arise from a two-log architecture in SnoopCompile:

  1. logmeths — C-level invalidations from jl_debug_method_invalidation. Records which MethodInstances are directly
  invalidated when a new method is inserted.
  2. logedges — Julia-level edge verification from staticdata.jl's verify_method. Records which CodeInstances fail
  re-validation when a precompiled image is loaded.

  The gap: verify_method in staticdata.jl:123–127 has an early-exit check:
  let max_valid2 = codeinst.max_world
      if max_valid2 ≠ WORLD_AGE_REVALIDATION_SENTINEL
          return 0, world, max_valid2   # returns with no logging to logedges
      end
  end

  CodeInstances already invalidated by C-level method insertion have max_world = 0, so they hit this early exit and log
   nothing to logedges. However, they still appear as cause in verify_methods entries for their transitive callers.
  SnoopCompile's invalidation_trees_logedges can't find these CIs in calleedict (they have no insert_backedges_callee
  entry), so they fall into mmibad → "unknown nothing".

  In the user's case: inserting continuous_events(sys::System) from ModelingToolkitTearing directly invalidates
  continuous_events(sys::AbstractSystem) (captured in logmeths). When callers of continuous_events(sys::AbstractSystem)
   are verified via verify_method, the cached CI has max_world=0 → early exit → callers logged as verify_methods(...,
  continuous_events_ci) with no prior logedges entry for the cause → "unknown nothing".

  The Fix (invalidations.jl)

  In invalidation_trees, before processing :unknown etrees:
  1. Build a MethodInstance → (tree_idx, InstanceNode) index across all mtrees
  2. For each "unknown" root, look up its MI in this index
  3. If found: adjust the callers' depths and attach them as children of the matching mtree node — properly attributing
   them to the inserting method
  4. Only truly unresolvable roots (pre-existing invalids from before the session) remain as "unknown"

[gbaraldi]

Can you add some tests?

[AayushSabharwal]

I'll get Claude to write something up