[CCR][FE Binlog] Dropping an async materialized view after FE restart emits an orphan DROP_TABLE event

## Problem

[CCR][FE Binlog] Dropping an async materialized view after FE restart emits an orphan DROP_TABLE event

## Minimal reproduction path

Enable database-level CCR metadata Binlog, create an asynchronous materialized view, persist a frontend image, restart the frontend, and make DROP the first operation involving that view after restart. Verify that neither an orphan CREATE_TABLE nor an orphan DROP_TABLE is emitted, matching the uninterrupted create/drop path.

## Expected result

Async materialized-view filtering is identical before and after frontend restart.

## Source

This report is a sanitized tracking record for Jira DORIS-28091. Internal hosts, paths, artifacts, build identifiers, and private logs are intentionally omitted.

Start with the minimal reproduction: enable database-level CCR metadata Binlog, create an asynchronous materialized view, persist a frontend image, restart the frontend, and make DROP the first operation involving that view. Compare filtering after restart with the uninterrupted create/drop path; done means neither an orphan CREATE_TABLE nor an orphan DROP_TABLE is emitted.

Written by the indexing model from the issue text.