[Improvement] Optimize schema emptiness checks and schema-scoped write fencing

### What would you like to be improved?

Schema deletion currently materializes complete child metadata objects only to determine whether a schema is empty. Because this check runs while holding the catalog/schema delete fence, large schemas can keep the lock longer than necessary.

Schema-scoped services also repeat the parent-lock transaction pattern. A future schema child type could accidentally write without taking the parent fence in the same transaction.

### How should we improve?

- Replace full child PO loading in the schema emptiness check with lightweight existence queries.
- Provide one schema-scoped transaction entry point that acquires the parent schema lock and executes the child writes in the same transaction.
- Migrate table, view, fileset, function, model, model version, and topic writes to the shared entry point.
- Cover the SQL and real service paths on H2, MySQL, and PostgreSQL.

Follow-up to #12456.

Start by tracing schema deletion and the repeated schema-scoped parent-lock transaction pattern in the SQL and real service paths. Review the table, view, fileset, function, model, model version, and topic writes, then run the relevant paths on H2, MySQL, and PostgreSQL. Done means lightweight existence checks, one shared fenced transaction entry point, migrated writes, and coverage for all three databases.

Written by the indexing model from the issue text.