Fix cascade deletion order in bulk delete action

[Copilot]

In the bulk delete action (configValidator.ts), connector.deleteRecord was called before cascadeChildrenDelete, meaning the parent record was deleted before child records were processed — the inverse of the correct order used in restApi.ts.

Changes

• configValidator.ts: Swapped the call order so cascadeChildrenDelete runs before connector.deleteRecord, matching restApi.ts

// Before (wrong)
await connector.deleteRecord({ resource, recordId });
await cascadeChildrenDelete(resource, recordId, { adminUser, response }, this.adminforth);

// After (correct)
await cascadeChildrenDelete(resource, recordId, { adminUser, response }, this.adminforth);
await connector.deleteRecord({ resource, recordId });

Why children-first: DB-level FK constraints prevent parent deletion while children still reference it. More importantly, if parent deletion fails after cascade completes, the parent record still exists — a consistent, recoverable state. The inverse (parent deleted, cascade fails) leaves orphaned child records referencing a non-existent parent.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.