[lyne7-sc]

Which issue does this PR close?

Closes #2603

Rationale for this change

Output backpressure can cause timing metrics to underflow when a native broadcast join falls back to sort-merge join. Negative values are ignored when reported to Spark, leaving the fallback time at zero even though the fallback executed.

This surfaced in PR #2599's CI: query result comparisons passed, but AuronBroadcastNestedLoopJoinSuite failed its positive fallback-time assertion. The affected timing code is already present in master.

What changes are included in this PR?

• Add an overall fallback timer and exclude waits for child output, pairing the existing output-wait deductions with a complete timing scope.
• Give the probe-side sorter a separate metrics collection so parent timing deductions cannot contaminate its compute time.
• Aggregate sort and merge computation once, preserve sort spill metrics, and add a backpressure regression covering both build sides.

Are there any user-facing changes?

Corrects timing metrics reported to Spark for native SMJ fallback. Query results and public APIs are unchanged.

How was this patch tested?

• Passed sorted_fallback_metrics_exclude_output_wait, which delays output consumption, checks results for both build sides, and verifies positive fallback and compute timing metrics.
• Verified in Spark UI that fallback timing remains positive under SQL output backpressure, with correct query results.

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

If yes, include: Generated-by: OpenAI Codex (GPT-6)

ASF guidance: https://www.apache.org/legal/generative-tooling.html

[slfan1989]

LGTM.

The timing scopes and separate sort metrics look correct. As a follow-up, a regression test with non-empty join keys would help verify sort timing and spill metric propagation.

[lyne7-sc]

Thanks for the suggestion. @slfan1989

Added a regression test covering non-empty join keys, sort timing, and spill metric propagation.