[Table Stream] Stream remains healthy after base table DROP or same-name recreation #67443

Tracking

• Tracking issue: [Tracking][Binlog] Binlog feature umbrella — all sub-issues tracked here #65265
• Fix pull request: [fix](stream) Mark streams stale when base tables are dropped #66287

Version

Reproduced on Doris commit f57e825d98 in a Cloud deployment.

What's Wrong?

After the base table of a Table Stream is dropped, force-dropped, or recreated with the same name and a different table ID, the old stream still reports a healthy state:

BASE_TABLE_TYPE = OLAP
ENABLED = true
IS_STALE = false
STALE_REASON = N/A

The stream continues to retain the old base-table identity instead of detecting that the referenced table is unavailable or has changed.

How to Reproduce?

1. Create a UNIQUE KEY merge-on-write table with ROW binlog enabled.
2. Create a MIN_DELTA Table Stream with initial rows enabled and record its stream ID.
3. Confirm that the stream is healthy and readable.
4. Drop the base table and inspect information_schema.table_streams.
5. Recover the original table and confirm that the stream becomes usable again.
6. Force-drop the base table, recreate a table with the same name but a different table ID, and inspect the old stream metadata again.

Actual Result

The old stream remains enabled and non-stale after the original base-table identity is permanently removed or replaced.

Expected Result

• A recoverable drop should make the stream unavailable or stale until the original table identity is recovered.
• A force drop should permanently make the old stream unavailable.
• Recreating a table with the same name must not bind the old stream to the new table ID.
• The stream metadata should retain enough identity information for diagnosis while reporting a clear stale reason.

Resolution

The fix is tracked by #66287.