Purging an app config allow-list entry leaves the RBAC nodes of its cascaded fragments

AppConfigAllowListPurger deletes the allow-list row, and the database cascades the delete to app_config_fragments through the (config_name, scope_type) foreign key (ON DELETE CASCADE). The generic purge path (V2WriteOps.purge_entity → _teardown) removes only the purged entity's own virtual entity and labels, so the cascaded fragments lose their rows but keep their virtual_entities rows and everything hanging off them by foreign key.

## Expected

- Purging an allow-list entry removes the virtual entity of every fragment the delete cascades to.

## What it needs

The same shape as the definition purge (BA-7879): the allow-list purge runs a service method whose repository deletes the fragments under the entry (an EntityBatchPurger selecting by the entry's config_name and scope_type) and then the entry, in one write_ops() transaction.

## Acceptance

- After purging an entry that has a fragment, no virtual_entities row remains for the fragment.
- A test seeds the entry, the fragment and their nodes directly and checks the graph after the purge.

## Related

Sibling of BA-7879 (definition purge), which found this gap on the allow-list path and left it out of scope.

JIRA Issue: BA-7882

Start by locating AppConfigAllowListPurger, V2WriteOps.purge_entity, _teardown, and EntityBatchPurger, then compare the definition purge described in BA-7879 with the allow-list path. Add a test that seeds an entry, fragment, and nodes directly, runs the purge through one write_ops() transaction, and verifies that no fragment virtual_entities row or dependent graph remains.

Written by the indexing model from the issue text.