# Profile reversible deletion

Profile remains a soft-deleted identity. It is not changed into a permanent
definition deletion like PermissionSet. Its User references are external and
restrict deletion. Physical FK CASCADE is not permission to discard settings.

The managed schema declares `retainOnSoftDelete` on parent-owned configuration
references: ProfileAppVisibility, ProfileTabSetting, ProfileCustomPermission,
and the retained legacy ProfileLayout / _System_ProfilePermission tables.
These rows have no individual tombstone: retain their bytes with the parent,
rather than hard-delete them and invent a second backup/recovery store.
Unmarked references still restrict deletion; retention never permits hard
deletion through the normal reference guard. No database migration is needed.

The existing Profile lifecycle owns activation:

- Before deletion, external references are checked in the Records transaction.
- After deletion, the existing carrier cleanup tombstones the profile-owned
  PermissionSet in that same transaction. Grant rows remain with the carrier.
- Permission Authoring target resolution excludes the deleted Profile/carrier.
- Navigation and effective custom permission reads require a live Profile.
  System/object/field/record-type grants require a live PermissionSet. The two
  retained legacy configuration tables are not current decision owners.
- Restore uses the existing carrier reactivation operation, not permission
  seeding. The canonical identity and administrator-authored grants survive.
- Permission State and cache invalidation retain their existing owners.

The disposable TiDB regression covers real Records Profile creation (including
its generated defaults), delete rollback, deletion, blocked authoring while
deleted, navigation revocation, restore/read-back, and an external User
reference rejecting deletion without changing the Profile or its carrier.
It also holds a real delete transaction open while an authoring Save reaches
target resolution, then proves that committing deletion rejects the Save
without resurrecting the carrier.

Separately, Runtime Record Mutation maps business conflicts to an operation's
INVALID_OPERATION result. PROCESSING_HALTED describes skipped sibling
operations, not a domain rejection; using it for a single DELETE made terminal
response validation fail with an internal error. Mutate/Status/replay tests
cover the corrected durable outcome without changing the public protocol.