[Subtask] Preserve owner-principal integrity during concurrent User or Group deletion

### Describe the subtask

OwnerMetaService resolves IDs before setOwner/batchSetOwners writes the relation. A different node can delete the owner principal and finish cleanup before the assignment inserts its row. Single and batch assignment races with User deletion reproduce on H2, MySQL, and PostgreSQL. The existing metadata-object orphan collector does not repair this case while the owned object remains live.

Fence and validate the User/Group owner endpoint by stable identity in the assignment transaction. Derive a consistent lock order for batches and principal/metalake deletion. Scope this task to owner-principal deletion; generic owned-object consistency is a separate design task.

Acceptance:
- Add explicit Group-owner coverage, both deletion winner orders, multiple-object batch rollback, and same-name recreation tests on all three SQL engines.
- Preserve ownership API, supported owner types, and assignment semantics.
- Verify no active ownership relation points to a deleted principal after the operations complete.

Existing orphan cleanup is handled by the companion GC task.

### Parent issue

https://github.com/apache/gravitino/issues/10238

Start with OwnerMetaService and the setOwner/batchSetOwners assignment paths, then trace User/Group deletion and principal cleanup transactions. Add coverage for Group owners, both deletion winner orders, batch rollback, and same-name recreation on H2, MySQL, and PostgreSQL; done means no active ownership relation points to a deleted principal while API and assignment semantics remain unchanged.

Written by the indexing model from the issue text.