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

## 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