Implement Pruner repository abstraction (parallel to Creator/Updater/Purger)

[fregataa]

Goal

Introduce a Pruner abstraction in the repository layer, in the same style as the existing Creator, Updater, and Purger patterns. This provides the foundation for per-entity prune implementations (session/kernel, vfolder, RBAC associations, etc.) that will be added under the parent epic.

Scope

• Add a Pruner base class / pattern under src/ai/backend/manager/repositories/ mirroring the existing purgers.py convention.
• Define the contract: bulk delete of records matching a hardcoded terminal-state condition per entity, optional until / before timestamp argument, optional limit, and a response carrying count and ids.
• Support an RBAC cascade option (default ON) so subclasses can extend the transaction to remove matching rows in association_scopes_entities before the entity rows are deleted.
• Use a single transaction with DELETE ... RETURNING; rely on PostgreSQL row locks for concurrency.
• Document conventions for per-entity Pruner subclasses (file layout, naming, registration with the repository).

Out of scope

• Concrete per-entity Pruner implementations (session/kernel, vfolder, RBAC) — tracked as separate sub-issues.
• Service-layer Action/ActionResult, processors, REST/GraphQL endpoints, SDK, CLI.
• Audit log integration (handled at service or processor layer).

Acceptance criteria

• Pruner base class exists and is importable alongside Creator / Updater / Purger.
• A reference example or test fixture demonstrates the expected subclass shape.
• Repository guide / pattern docs updated to reference Pruner where Creator/Updater/Purger are listed.
• Quality gates pass: pants fmt, fix, lint, check, test.

JIRA Issue: BA-5936