System Config delete blockers fail for Division when Discipline is reached through CASCADE

[acwhite211]

Describe the bug

This is essentially the same underlying problem as #7797, but through a different entry point.

The hot fix in #7833 only handles the case where Discipline is the base table passed to the delete blockers endpoint.

The same issue still occurs when a non-Discipline table cascades into Discipline during blocker collection. A notable example is Division in the System Config tool.

Because Discipline -> Division is on_delete=CASCADE, collecting delete blockers for a Division also collects delete blockers for its related Discipline. The endpoint does not apply the same discipline-specific cleanup/handling in that cascaded case, so discipline-owned setup rows such as Spexportschema_exportmapping can still be returned.

That causes the frontend to hit the same kind of failure seen in #7797, because it attempts to treat Spexportschema_exportmapping as a regular datamodel table.

To reproduce

1. Create or use a Division that has an associated Discipline.
2. Ensure that Discipline has discipline-scoped setup data that produces the same blocker chain as System Config unknown table error: Spexportschema_exportmapping #7797, such as export schema mapping rows.
3. Open the Division record in the System Config tool in Specify.
4. Trigger delete blocker collection for that Division.

Actual behavior

The delete blockers response can include setup/join-table rows such as:

• Spexportschema_exportmapping

This leads to the front-end error when it tries to resolve that table name.

Expected behavior

Delete blocker collection for a parent record such as Division should apply the same discipline-specific handling used when Discipline is the base table.

The endpoint should not surface discipline-owned setup/join-table rows that are supposed to be cleaned up as part of the discipline delete flow.