[feature](cloud) Support Cloud Table Stream control plane

[Yukang-Lian]

What problem does this PR solve?

Issue Number: None

Related PR: #65810

Problem Summary:

Table Stream already provides incremental consumption in storage-compute integrated deployments, where FE owns each partition offset. In Cloud mode, the target-table commit is finalized by MetaService, so keeping offsets in FE cannot atomically commit target data and advance Stream offsets.

This PR adds the Cloud Table Stream control plane:

• treats FE Catalog as the authority for Stream existence and binding, and stores only Latest and Versioned per-partition offsets in MetaService;
• reuses the existing Index prepare, commit, Drop Index Log, Recycle Index, and InstanceRecycler lifecycle without creating Stream Mapping keys or physical tablets;
• resolves one statement-level read snapshot, including clone-chain Offset inheritance;
• performs expected-offset CAS and target-table commit in the same immediate FDB transaction, with no lazy-commit fallback;
• keeps Create retries idempotent without overwriting offsets that consumption has already advanced;
• carries affected Stream identities through DROP PARTITION so the partition recycler removes the corresponding Latest and Versioned offsets;
• preserves the existing non-Cloud Table Stream path.

This draft depends on #65810 for the Cloud Row Binlog data plane. Before Cloud E2E is enabled, the integration must confirm that every visible partition, including an empty partition and a newly added partition, has an authoritative VersionPB.visible_tso and empty-boundary TSO. The control plane intentionally fails when that metadata is missing instead of treating metadata loss as an empty partition.

Rolling upgrade rule: upgrade all MetaService nodes before enabling the FE Cloud Table Stream path. Once enabled, MetaService rollback requires stopping Stream consumption first because an older MetaService does not understand Stream offset updates.

Release note

Add the storage-compute separated Table Stream control plane. End-to-end availability depends on the Cloud Row Binlog data plane in #65810.

Check List (For Author)

• Test

  • Regression test
    • table_stream_p0 and row_binlog_p0: 15 suites passed on the branch baseline.
  • Unit Test
    • Cloud MetaService Create, Query, Update, key, clone-chain, recycler, checker, and operation-log tests passed.
    • FE Cloud catalog and Table Stream manager tests: 8 tests passed after the Offset-only metadata change.
    • The earlier full FE Table Stream, transaction, drop, planner, and MV rewrite baseline passed.
  • Manual test
    • ./build.sh --cloud passed.
    • NODE_OPTIONS=--openssl-legacy-provider ./build.sh --fe passed with Checkstyle.
    • Cloud C++ formatting passed, and changed-line clang-tidy passed for all modified production C++ files. The existing Cloud HTTP test target still cannot be analyzed because its compile command exposes pre-existing private-API diagnostics.
  • 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. Cloud Table Stream uses MetaService-managed offsets, immediate atomic consumption commits, and FORCE-only drop semantics. Non-Cloud behavior is unchanged.

• Does this need documentation?

  • No.
  • Yes. The implementation and test designs have been reviewed; public user documentation should be published when [feat](row binlog)：support cloud binlog and independent binlog tablet #65810 completes the end-to-end feature.

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?