Track provenance of fallback reasons copied through shared expression nodes

[sunchao]

Describe the bug

Fallback reasons have a separate provenance problem from the coverage tags fixed in #5471. If a stale FALLBACK_REASONS tag reaches a shared expression such as Literal.TrueLiteral, an unrelated failed conversion can lift it onto its original expression owner. Operator roll-up also collects reasons from every descendant. A nonempty stale reason can then satisfy reportUnexplainedFallback, hiding an otherwise unexplained fallback when spark.comet.explain.fallback.strict.enabled is enabled.

This is a source-confirmed propagation path conditional on a stale tag; it is not a reproduced sequence of two SQL queries. The proposed dynamic partition pruning origin still needs investigation. Spark 4.1.3's PlanDynamicPruningFilters replaces the subquery with a DynamicPruningExpression(TrueLiteral) wrapper, and its non-AQE rule runs before Comet conversion. That source alone does not establish that the shared literal receives a fallback reason.

Steps to reproduce

Add focused tests that preserve and restore the singleton's previous tags:

1. Seed a distinctive stale fallback reason on Literal.TrueLiteral.
2. Convert an expression containing that literal and decimal arithmetic, so decimal promotion rebuilds the surrounding tree. Force the conversion to decline and check which reasons are lifted onto the original owner.
3. Exercise operator roll-up and the strict fallback check with an operator that otherwise lacks an explanation. Verify that the planted reason cannot masquerade as an explanation for the current conversion.
4. Also test legitimate literal fallback reasons, including an unsupported literal type and explicitly disabled literal support.

These are regression targets, not a claim that all four tests already exist or that the singleton contamination producer has been reproduced.

Expected behavior

An expression or operator should report reasons belonging to its current conversion, without diagnostics from unrelated queries. The strict check should continue to detect an otherwise missing reason. Legitimate reasons attached to literals must remain visible: applying the coverage-only isNeverTagged filter to fallback reasons would discard real diagnostics.

Additional context

The relevant paths at the reviewed head are the failure-only fallback lift, operator roll-up and the strict check, and legitimate literal fallback reasons.

The potential DPP origin should be checked against Spark 4.1.3's actual replacement, not assumed from coverage-tag behavior. Related earlier work: #5229 and #5230. Keep this follow-up separate from #5471, which only changes coverage metadata.