analyze-performance-traces

# Analyze Performance Traces End with an evidence chain from trigger to exact source. Fix the earliest proven cause. Never turn an API name or an inclusive duration into a causal claim without checking execution context. ## Choose the evidence mode State which mode applies before making findings: 1. **Trace-backed**: a trace is supplied or discoverable. Durations, processes, threads, and event ordering may be reported from it. 2. **Reported-finding audit**: the user supplies durations or a chain but not the artifact. Treat those details as leads. Confirm current source paths and trigger conditions; label the durations, thread, and invalidation scope unverified. 3. **Source-only**: no trace-derived lead exists. Report hypotheses, not measured bottlenecks. Do not block a reported-finding audit merely because the original trace file is absent. If the user asks for safe implementation after the source chain is proven, proceed within authorization; require a comparable post-change trace before claiming millisecond or frame-rate improvement. If neither a trace nor a concrete lead exists, ask for the smallest reproducible capture unless the user explicitly wants source-only analysis. ## Start safely 1. Read repository instructions, nearest area instructions, relevant architecture docs, current diff, and validation policy. Record Git baseline before editing. 2. Discover trace artifacts without printing them wholesale. For each candidate: ```sh ls -lh TRACE.json head...