Persisted `loop(db, t)` table pins its source: `DROP TABLE t SYNC` never returns

Why we believe this is a bug: InterpreterCreateQuery.cpp:2606 -> throwIfTableFunctionCannotBeUsedToCreateTable (InterpreterCreateQuery.cpp:882) asks only the outermost table function, and TableFunctionLoop (TableFunctionLoop.cpp:27) never overrides canBeUsedToCreateTable, so the table is created. The first read memoises StorageLoop inside the StorageTableFunctionProxy (StorageTableFunction.h:38-48), and StorageLoop::inner_storage (StorageLoop.h:35) is the source table's StoragePtr, so the drop worker's uniqueness test (DatabaseCatalog.cpp:1661) never selects the source and waitTableFinallyDropped (DatabaseCatalog.cpp:1843) polls forever.

Affected locations:

• src/TableFunctions/TableFunctionLoop.cpp:27 — class TableFunctionLoop - no canBeUsedToCreateTable override, unlike the five classes this PR changes
• src/Storages/StorageLoop.h:35 — StorageLoop::inner_storage holds the source table's StoragePtr
• src/Interpreters/InterpreterCreateQuery.cpp:882 — the veto this PR wires up, consulted for the outermost function only
• src/Interpreters/DatabaseCatalog.cpp:1661 — drop worker skips a marked-dropped table whose StoragePtr is not unique
• src/Storages/StorageFactory.cpp:132 — ENGINE = Loop already refused for the same 'table function only' reason

Impact: A DROP TABLE on the source never completes and holds a server thread; the table stays in system.dropped_tables indefinitely. Recovery requires dropping the persisted loop table, KILL QUERY, or a restart. Not a regression of this PR - the acceptance predates it - but it leaves the hazard the PR is closing reachable through one more registered name.

DROP TABLE IF EXISTS tab;
CREATE TABLE tab (col String) ENGINE=Loop; -- { serverError INCORRECT_QUERY }

DROP TABLE IF EXISTS src_03307;
DROP TABLE IF EXISTS tab_loop_03307;
CREATE TABLE src_03307 (id UInt32) ENGINE = MergeTree ORDER BY id;

-- A persistent table over `loop` keeps the source table's storage object alive, so `DROP TABLE src_03307 SYNC` never returns.
CREATE TABLE tab_loop_03307 AS loop(currentDatabase(), 'src_03307'); -- { serverError BAD_ARGUMENTS }

DROP TABLE IF EXISTS tab_loop_03307;
DROP TABLE IF EXISTS src_03307;

Give TableFunctionLoop the same one-line override the five classes get here: bool canBeUsedToCreateTable() const override { return false; }. Trade-off: that also refuses replay of CREATE TABLE ... AS loop(...) definitions stored by earlier versions - the same backward incompatibility this PR already accepts. The alternative, keeping persistence legal and having StorageLoop hold a StorageID resolved per read, keeps such tables working but touches StorageLoop/ReadFromLoopStep.

Open risks:

• CREATE TABLE p AS loop(mergeTreeIndex(db, t)) is accepted too but measured NOT to pin (the drop returned at once) - ReadFromLoopStep re-resolves the inner table function, so only the plain loop(db, table) form holds the source.
• DROP DATABASE ... SYNC over the same database was not measured; it drops member tables in catalog order, so whether it blocks depends on whether the persisted table is dropped before the source.

Found during automated review of PR #118969. Severity P2 · Finding h_pr118969_001