Deleting a role, group, connector or saved query is immediate and final

Content has three states and a deliberate hard delete: `Archived` is recoverable, and `DELETE /api/contents/{id}/erase` is the irreversible GDPR path, kept separate from archiving on purpose. That distinction is right.

Nothing else in the product has it. Every other delete is a hard delete:

- `Features/Roles/Delete/Endpoint.cs:90` — `_session.Delete(role)`
- `Features/UserGroups/Delete/Endpoint.cs:49` — `_session.Delete(group)`
- `Features/Connectors/Endpoints.cs:378-379` — the connector and every one of its secrets
- `Features/Queries/Endpoints.cs:240` and `Features/Requests/Endpoints.cs:295`

Marten has soft deletes as a document policy: `.SoftDeleted()`, with `MaybeDeleted()` / `IsDeleted()` for queries that want the removed rows back.

## Why it matters

A deleted role takes its permission assignments with it. A deleted connector takes its secrets, so restoring it means re-entering credentials that may live nowhere else. A deleted saved query is somebody's report.

Audit records that a delete happened and by whom. It does not hold the payload, so it cannot answer "what was in it" — which is the only question that matters at 4pm on the day someone deletes the wrong role on a client instance.

An agency running a client's instance is the case this product is aimed at, and it is exactly where "restore that, please" has no answer today.

## What to change

Soft delete on the admin-object types above, with a window and a purge sweep — retention that #622's primitive should own rather than another timer.

The API shape wants care. Options worth arguing in the thread before code:

- `DELETE` soft-deletes and a separate route purges, mirroring content's archive-versus-erase split. Consistent with what exists, and it changes the meaning of an existing verb.
- `DELETE` keeps its meaning and a `?purge=true` or a header opts into permanence. Uglier, and no existing client breaks.

## What has to stay true

- The uniqueness rules. A soft-deleted role holding its name means a new role cannot take that name, and if the index ignores deleted rows then restoring one can collide. Pick which, and test the collision.
- Authorisation on the restore path is not weaker than the delete path. Restoring a role restores permissions.
- Erasure stays absolute. Whatever ships must not become a way for erased personal data to persist somewhere recoverable, which would be a compliance regression, not a feature.
- Connector secrets: a restored connector must not resurrect a credential that was rotated in the meantime. Restoring the connector shell without its secrets may be the right answer.

## Done when

- Deleting one of these types is recoverable for a documented window, with a test that restores one and proves it works again.
- The purge path is tested and irreversible.
- `docs/access-control.md` says what a restored role does to permissions.

Found while auditing the stack for unused Marten capabilities.

Start with the delete entry points in Features/Roles/Delete/Endpoint.cs, Features/UserGroups/Delete/Endpoint.cs, Features/Connectors/Endpoints.cs, Features/Queries/Endpoints.cs, and Features/Requests/Endpoints.cs, then review #622's retention primitive. Resolve the API and uniqueness choices before implementation. Done means recoverable deletes and tested restoration, an irreversible purge path, and docs/access-control.md describing restored role permissions.

Written by the indexing model from the issue text.