follow-up: recover from poisoned glob_cache mutex instead of silent no-op in collect_files.rs

[carlos-alm]

Deferred from PR #2061 review.

Original reviewer comment: #2061 (comment) (inline comment on crates/codegraph-core/src/domain/graph/resolve.rs, about workspace_resolved_cache's mutex).

Context: While fixing the flagged issue in resolve.rs (silent no-op via if let Ok(mut set) = ...lock() { ... } on a poisoned mutex, instead of recovering via unwrap_or_else(|poisoned| poisoned.into_inner())), I searched the rest of the codebase for the same anti-pattern and found one more instance on a different, unrelated mutex: glob_cache() in crates/codegraph-core/src/domain/graph/builder/stages/collect_files.rs, guarding a compiled-glob-pattern cache (GlobCache). Three call sites share the pattern:

• clear_glob_cache() (test-only): if let Ok(mut cache) = glob_cache().lock() { cache.clear(); }
• build_glob_set() read path: if let Ok(cache) = glob_cache().lock() { if let Some(set) = cache.get(patterns) { return Some(set); } }
• build_glob_set() write path: if let Ok(mut cache) = glob_cache().lock() { cache.insert(patterns.to_vec(), arc.clone()); }

If a thread panics while holding this lock, all three silently no-op afterward — reads permanently miss the cache (falling back to recompiling the GlobSet, which is safe but slower) and writes are silently dropped. Lower severity than the resolve.rs case (a missed cache write here doesn't produce incorrect results, just repeated recomputation), but the same fix applies for consistency: recover the poisoned guard via unwrap_or_else(|poisoned| poisoned.into_inner()) at all three call sites, and existing test infrastructure (GLOB_CACHE_TEST_LOCK) shows the established pattern for this already.

This is out of scope for PR #2061, which doesn't touch collect_files.rs at all — flagging as a separate, standalone follow-up rather than expanding that PR's diff.