fix: count ReusedSubquery and CometSubqueryBroadcast correctly in extended explain

[andygrove]

Which issue does this PR close?

Part of #5203. Items 1 and 2 from the issue are fixed here; item 3 (counting reused
exchanges once) is deferred to a follow-up, as the issue itself suggested it could be.

Rationale for this change

The operator coverage summary produced by ExtendedExplainInfo
(Comet accelerated N out of M eligible operators (X%)) puts two node kinds in the
un-accelerated Spark bucket even though neither is un-accelerated Spark work. Every
reuse site and every DPP subquery broadcast therefore drags the reported percentage
down, and fully accelerated plans report less than 100%.

The same counts feed the comet metrics source via CometMetricsListener ->
CometSource, so the skew also biases the acceleration.ratio gauge rather than being
confined to EXPLAIN output.

What changes are included in this PR?

1. ReusedSubqueryExec is no longer counted as an un-accelerated Spark operator.
   It is pure reuse bookkeeping and a LeafExecNode, so it joins the ignore list
   alongside the other wrapper nodes. The subquery it points at is counted where that
   subquery is shown.

2. CometSubqueryBroadcastExec now mixes in CometPlan and counts as accelerated.
   On the blast radius the issue asked about: the other CometPlan match sites
   (EliminateRedundantTransitions.hasCometNativeChild, foreachUntilCometInput,
   CometShuffleExchangeExec.isCometPlan) all reach nodes through children, and a
   BaseSubqueryExec hangs off a DynamicPruningExpression rather than children, so
   none of them observe the new type. The one site that does newly match it is
   CometExecRule's "never replace" guard, whose only effect is suppressing a
   misleading info message, and where the new classification is the correct one.

The plan text rendered by extended explain is unchanged. Only the summary line moves:
all 133 golden diffs are confined to that one line, with no tree edits and no golden
files added or removed. 101 of the changed plans now report 100% acceleration, and
across all 158 goldens the count at 100% goes from 21 to 122. No plan's percentage
decreases.

approved-plans-v1_4/q1, the example from the issue:

-Comet accelerated 47 out of 49 eligible operators (95%). ...
+Comet accelerated 48 out of 48 eligible operators (100%). ...

The denominator drops by one because ReusedSubquery leaves the eligible set entirely,
and the numerator rises by one because CometSubqueryBroadcast moves from the Spark
bucket to the Comet bucket.

Also documents in understanding-comet-plans.md which nodes are excluded from the
counts.

How are these changes tested?

New CometCoverageStatsSuite covers both cases directly: a ReusedSubquery
contributes no operators of any kind, and wrapping a plan in
CometSubqueryBroadcastExec adds exactly one accelerated operator while leaving the
Spark operator and transition counts untouched.

TPC-DS plan stability goldens were regenerated for Spark 3.4, 3.5, 4.0, 4.1 and 4.2.
Both plan stability suites then pass in verification mode against the regenerated
goldens on all five versions (135 tests per version, 10 suite runs, no failures).
CometCodegenSuite and the new suite also pass on the default profile.

[mbutrovich]

Just docs changes. I understand if you want to defer those to a fast followup PR.

[mbutrovich]

CometSparkToColumnarExec.nodeName renders as either CometSparkColumnarToColumnar or CometSparkRowToColumnar, depending on whether child.supportsColumnar is true. The transition-nodes bullet only lists CometSparkRowToColumnar. Since generateTreeString matches on the Scala type rather than the rendered name, both variants are already excluded from the operator counts today. Could the bullet list both names, so a reader who sees CometSparkColumnarToColumnar in their own explain output can tell it's covered by this list too?

[mbutrovich]

ReusedExchangeExec is matched in the same ignore arm as AdaptiveSparkPlanExec, InputAdapter, WholeStageCodegenExec, QueryStageExec, and AQEShuffleReadExec, but it isn't mentioned anywhere in this new section. It also behaves differently from the wrappers that are listed: getActualPlan unwraps it to its child, so a reused exchange subtree is counted once per reference rather than once total (the item 3 double-counting left open in #5203). Since this section's purpose is explaining what's excluded from the counts and why, could it also cover ReusedExchangeExec, including the caveat that it isn't cleanly excluded the way the others are?

[andygrove]

Just docs changes. I understand if you want to defer those to a fast followup PR.

Thanks, would prefer separate PR for docs changes to save CI time

[mbutrovich]

Approved pending CI, thanks @andygrove. We'll do a docs followup.