[BUG] Namespace deletion can orphan discovery records

### Current Behavior

Namespace deletion checks several namespace-scoped resources before deleting the namespace, but it does not check discovery records.

`NamespaceServiceImpl.delete()` blocks deletion when the namespace still has rules, selectors, namespace-plugin relations, metadata, or app auth. Discovery records are also namespace-scoped, but they are not consulted before `namespaceMapper.deleteByIds(ids)` is called.

Because discovery rows store `namespace_id` without database-level foreign-key enforcement, deleting a namespace can leave discovery data pointing at a namespace that no longer exists.

### Expected Behavior

Namespace deletion should either block when discovery records exist under the namespace, or delete/clean those discovery records consistently with the rest of the namespace-scoped data model.

### Steps to Reproduce

1. Create a namespace.
2. Create discovery data under that namespace, without creating selectors/rules under the same namespace.
3. Delete the namespace.
4. The namespace delete can succeed while discovery rows remain with the deleted namespace id.

### Impact

Namespace deletion can orphan discovery configuration, causing stale data and inconsistent admin state.

### Code Location

- `shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/NamespaceServiceImpl.java`
- `delete()` checks multiple scoped resource tables but not discovery.
- `db/init/mysql/schema.sql`
- discovery stores `namespace_id` without FK cleanup.

Start in shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/NamespaceServiceImpl.java at delete(), and trace how discovery records are represented and removed. Compare the existing namespace-scoped checks with db/init/mysql/schema.sql, then reproduce deletion with discovery data but no selectors or rules. Done means deletion either blocks appropriately or leaves no discovery rows pointing to the deleted namespace.

Written by the indexing model from the issue text.