Plugin delete reports success but the record persists

Deleting a plugin from the plugin edit page (the ... menu, Delete, confirm) shows the "Plugin deleted." toast, but the record survives: reloading the plugin page and the edit page still resolves it, and a later submission of the same name gets a -1 suffixed slug because the "deleted" row still owns it.

Looking at apps/cursor/src/actions/delete-plugin.ts, the delete goes through the user-scoped Supabase client with .delete().eq("id", id).eq("owner_id", userId). If the RLS delete policy does not match, that affects zero rows without raising an error, so the action returns success without deleting. A zero-row delete reporting success would explain what we see.

Happened twice to us on cursor.directory (account auscaster):

1. Deleted the manually created plugin at /plugins/ausca. Toast said deleted; the record is still live.
2. Resubmitted the same plugin via the Auto (GitHub) flow from https://github.com/auscahq/ausca. Because the old row survived, the new one landed at /plugins/ausca-1 with all six components correctly auto-scanned (one MCP server, five skills).

The cleanup we would like, in preference order:

1. Preferred: delete only the stale /plugins/ausca record (one hand-made component, superseded) and move the complete /plugins/ausca-1 record onto the freed ausca slug. That record is fully scanned and correct; a slug rename preserves it as-is with no resubmission.
2. Alternatively, hard-delete both rows and we resubmit once cleanly.

Happy to provide any account confirmation you need. Thanks for the directory, the Auto scan flow detected all six of our components perfectly.

Start with apps/cursor/src/actions/delete-plugin.ts and reproduce deletion from the plugin edit page through the user-scoped Supabase client. Inspect the matching RLS delete policy and verify the action distinguishes a zero-row delete from a successful deletion; done means the row is gone after reload and a later submission can use the original slug.