Optimize TraceQueryService.sortSpans from O(N^2) to O(N) (#13831)

`TraceQueryService.sortSpans()` builds the parent-child span tree for trace detail rendering. The existing implementation runs in O(N^2):

- `findRoot()` iterates all N spans and, for each, linearly scans the full list to check whether its parent exists.
- `findChildren()` is called per root and recursively scans the full list at each node to find direct children.

For traces with deep call chains or many parallel spans this becomes noticeable latency on every trace detail query (a UI hot path).

This PR pre-indexes the span list once per trace and turns the algorithm into O(N):

- `Set<String> segmentSpanIds` — membership check used by `findRoot` to decide if a span has a parent in the current list.
- `Map<String, List<Span>> childrenByParentSegmentSpanId` — direct lookup for `findChildren`.

The three helpers (`sortSpans`, `findRoot`, `findChildren`) are now package-private `static` because they have always been pure functions — no instance state. This also makes them directly unit-testable.

## Behavior

Preserved from the previous implementation:
- Root spans sorted by `startTime`.
- Children traversed in input order (DFS).
- Orphaned spans (parent not in the list due to lost/sampled segments) treated as roots.
- Cross-segment ref parents resolved via the shared `segmentSpanId` namespace (`segmentId + 'S' + spanId`).