[fix](fe) Fix view columns losing colUniqueId in lazy materialization

[englefly]

What problem does this PR solve?

When querying columns through a view with TopN + lazy materialization,
SlotReference.withOneLevelTableAndColumnAndQualifier() incorrectly replaced
originalColumn with the view's Column object (which has uniqueId=-1).
This caused colUniqueId=-1 in the physical plan, making BE unable to find
the column during the two-phase read (lazy materialize) fetch, resulting in
"returned block with row count 0 not match request row id count" error.

The fix preserves the original base table Column (which carries the correct
uniqueId) instead of overwriting it with the view's Column.

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[englefly]

run buildall

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100% (0/0) 🎉
Increment coverage report
Complete coverage report

[englefly]

run buildall

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100.00% (1/1) 🎉
Increment coverage report
Complete coverage report

[englefly]

run cloud_p0

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 0.15% (1/661) 🎉
Increment coverage report
Complete coverage report

[englefly]

/review

[github-actions]

Requesting changes because the PR only fixes one of the two MySQL metadata paths.

Finding

1. Alias.toSlot() now preserves oneLevelColumn, which fixes the normal result-set metadata path that goes through NereidsPlanner -> FieldInfo. But server-side prepared statements still go through PrepareCommand.run() -> StmtExecutor.planPrepareStatementSlots() -> PrepareCommandPlanner (ANALYZED_PLAN) -> StmtExecutor.sendStmtPrepareOK() (fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/PrepareCommand.java:129-139, fe/fe-core/src/main/java/org/apache/doris/qe/StmtExecutor.java:1699-1713, fe/fe-core/src/main/java/org/apache/doris/qe/StmtExecutor.java:1986-1993). That path still serializes originalTable/originalColumn and ignores the oneLevel* metadata that normal queries use in fe/fe-core/src/main/java/org/apache/doris/nereids/NereidsPlanner.java:656-676, so useServerPrepStmts=true still exposes base-table metadata for view columns.

Critical checkpoints

• Goal of the task: Partially accomplished. The lazy-materialization fix looks correct, and the normal result-set metadata path looks fixed. The view-metadata goal is still unmet for COM_STMT_PREPARE.
• Is the change small and focused: Yes.
• Concurrency: Not involved.
• Lifecycle/static initialization: Not involved.
• Configuration: No new config.
• Compatibility/storage format: No compatibility or storage-format change.
• Parallel code paths: Not fully handled. The prepared-statement metadata path was not updated.
• Special conditional checks: No new risky conditionals.
• Test coverage: Incomplete. The new lazy-materialization regression is good, but there is no useServerPrepStmts=true regression for view metadata.
• Observability: Not applicable.
• Transaction/persistence/data writes: Not involved.
• FE-BE variable passing: Not applicable for this change.
• Performance: Neutral.
• Other issues: None beyond the blocking prepared-statement path.

[github-actions]

PR approved by at least one committer and no changes requested.

prepare stmt的bug不在这个pr的修改范畴，如果有bug，另外开pr fix