harden get_critical_path against recursion/complexity DoS

[jkowall]

Motivation

• The previous critical path implementation used recursive parent↔child bouncing and rescanned all siblings on each return, which creates O(N^2) work and deep recursion for attacker-controlled high fan-out traces and exposes the MCP server to CPU/stack DoS.

Description

• Replaced recursive parent/child bouncing in computeCriticalPath with an iterative traversal loop to avoid deep recursion and repeated rescans (file criticalpath/criticalpath.go).
• Introduced a childSelector cache that pre-sorts each parent's children by end time and advances via an index to avoid full sibling rescans (functions newChildSelector, findLastFinishingChild, and sortedChildrenByEndTimeDesc).
• Kept existing critical-path section semantics and preserved handling of returningChildStartTime while eliminating quadratic behavior.
• Added a large-fanout regression test TestComputeCriticalPath_FlatTraceLargeFanout to exercise flat traces with many siblings (file criticalpath/criticalpath_test.go).

Testing

• make fmt completed successfully in this environment.
• Unit tests for the critical-path package were run with go test ./cmd/jaeger/internal/extension/jaegermcp/internal/criticalpath and passed.
• make lint and the repository-wide make test were started but the long-running lint/test jobs did not complete within this environment, so full-repo linting and test-suite confirmation could not be completed here.

---

Codex Task

[github-actions]

Hi @jkowall, thanks for your contribution! To ensure quality reviews, we limit how many concurrent PRs new contributors can open:

• Open: 6
• Limit: 1

This PR is currently on hold. We will automatically move this into the review queue once your existing PRs are merged or closed.

Please see our Contributing Guidelines for details on our tiered quota policy.