feat(domain): introduce error slugs (#12030)

# Which Problems Are Solved

As part of https://github.com/zitadel/zitadel/issues/11917 we want to
introduce error slugs so (API) clients can rely on stable,
machine-readable errors and act accordingly.

# How the Problems Are Solved

- Added a `NewSlug` helper function in the domain package.
- Added `ErrorDetails` to the `ZitadelError`
- Added an `zitadel.error.v2.ErrorDetail` proto message
- Updated the connectRPC error interceptor to map new slug based errors
to the new `ErrorDetail`
- Defined some common slugs and error functions like internal errors
- Defined (session) specific slugs used in the `DeleteSession` and
`CheckUser` functions and replaced old implementations
- Updated integration tests to check specific errors if the relation
database feature is enabled
- Updated doc and guideline to reflect the latest changes and decisions
- Updated DeleteSession endpoint API to list possible slugs

# Additional Changes

None

# Additional Context

- closes #11957

---------

Co-authored-by: Wim Van Laer <[email protected]>

apps/docs/content/apis/statuscodes.mdx

@@ -18,3 +18,14 @@ sidebar_label: GRPC Status Codes
 | 13          | INTERNAL            | 500              | Internal            | Internal errors. This means that some invariants expected by the underlying system have been broken. This error code is reserved for serious errors.                                                                      |
 | 14          | UNAVAILABLE         | 503              | Service Unavailable | The service is currently unavailable.                                                                                                                                                                                     |
 | 16          | UNAUTHENTICATED     | 401              | Unauthorized        | The request does not have valid authentication credentials for the operation.                                                                                                                                             |
+
+## Error details and slugs
+
+For stable `v2` APIs, services import `zitadel/error/v2/error.proto` so reflection-aware clients can resolve `zitadel.error.v2.ErrorDetail`.
+
+When present, inspect `ErrorDetail.slug` first for programmatic handling. Slugs are stable machine-readable identifiers such as `user.already_exists`.
+
+Use `ErrorDetail.message` for developer diagnostics, not end-user text. Prefer mapping slugs to your own localized messages in clients.
+
+This slug-based handling is currently relevant for backend/domain paths that run with relational-storage-backed logic.
+Do not assume it for `v1`, `v2beta`, or `v3alpha` APIs or when using a v2 endpoint without having the relational storage feature enabled.