[Detection] Default-import context threading in resolveExportedMatches (A3 follow-up)

[AndresL230]

Summary

PR #110's A3 barrel re-export work added handling for export { default } from "./a", but the default-import context threading in resolveExportedMatches is fragile when a barrel mixes a default re-export with named re-exports whose source happens to call the default's provider.

Repro shape

// barrel.ts
export { default } from "./a";   // a.ts default-exports an OpenAI client
export { ask } from "./b";       // b.ts also makes openai calls via a different path

// consumer.ts
import client, { ask } from "./barrel";
client.chat.completions.create(...);
ask(...);

When the barrel mixes shapes, the resolver may incorrectly attribute one to the other's provider context. The tested fixture in PR #110 works; the failure mode appears when barrels are heterogeneous.

What to do

• Add an explicit "default vs. named" disambiguation pass in src/ast/cross-file-resolver.ts.
• Each re-export entry should carry its own provider-resolution context — don't share state across the barrel.
• Audit fixture in src/test/fixtures/a3-followup/.
• Test in src/test/a3-default-import-threading.test.ts.

Acceptance criteria

• Mixed-shape barrel resolves each export to its true provider, not a shared one.
• No regression to existing A3 tests (5 barrel shapes from PR fix(detection): A3 + A5 — barrel re-exports + factory/DI/aliased clients (closes #75, #77) #110).
• No regression to detection precision/recall on benchmark corpus.

Reference

Memory: a3_a5_pr_status.md — "Default-import context threading in resolveExportedMatches — works for tested fixture but fragile when a barrel mixes…"