fix: TableScan should recurse into provider logical plan in map_children

[shifluxxc]

Which issue does this PR close?

• Closes #19272

Rationale for this change

LogicalPlan::TableScan is currently treated as a leaf node in map_children, but some table providers (such as views) expose their own logical plan via TableSource::get_logical_plan(). Because of this incorrect leaf assumption, logical plan visitors and optimizer passes fail to recurse into the underlying logical plan. This leads to missed optimizations and incomplete rewrites when a scan represents a view or other provider-defined logical plan.

What changes are included in this PR?

• Updated LogicalPlan::map_children to:
  • Detect when a TableSource returns a logical plan
  • Recurse into that inner plan
  • Reconstruct the TableSource using replace_logical_plan after transformation
• Added two unit tests:
  • test_table_scan_with_inner_plan_is_visited ensures recursion occurs for providers with an inner plan
  • test_table_scan_without_inner_plan_is_not_visited ensures behavior remains unchanged when no inner plan exists

Are these changes tested?

Yes. Two dedicated unit tests validate:

1. The inner plan is visited and rewritten correctly when the provider exposes one.
2. No recursion happens when the provider does not expose a logical plan.

Are there any user-facing changes?

No