Docs: document the platform-enforced "Can't delete last `_owner`" rule

[mitselek]

TL;DR

Attempting to DELETE the last _owner property entry on any entity returns HTTP 403 with message "Can't delete last _owner". This is a useful platform guarantee — entities can never become ownerless — but isn't surfaced in the docs.

Reproduction (probed 2026-05-17 against api.entu.app/polyphony)

DELETE /polyphony/property/<id of last _owner property>
→ HTTP 403
{
  "error": true,
  "status": 403,
  "statusText": "Can't delete last _owner",
  "message": "Can't delete last _owner"
}

Applies to every entity type (tested with a generic _type=entity probe). Deleting a non-last _owner succeeds normally.

Implication

Downstream apps can rely on this guarantee — they don't need to build their own "minimum-owner" enforcement at the platform layer. App-level invariants (e.g., "at least one owner must also be a member") can layer on top.

For ownership transfer: add the new owner first, then remove the old one (standard pattern enabled by this rule).

Suggested doc note

At https://www.entu.ee/api/properties/ in the property-deletion rules table, add an explicit row for "_owner (last one): cannot be deleted — at least one _owner must remain". (There's already an analogous row hinted at in some sections; making it canonical helps.)

Related: polyphony case study E1 — https://github.com/entu/research/blob/main/docs/case-studies/2026-05-polyphony-on-entu.md

[mitselek]

Follow-up probes — adjacent cases we hadn't tested

The original probe covered the most direct case: DELETE of the last explicit _owner property → 403. Two adjacent cases were raised post-filing and probed 2026-05-18:

Case 1: Flip _inheritrights from true to false on a child

Created parent + child (inheritrights: true), waited for cascade, then flipped child._inheritrights to false. Result: child's _owner entries persisted unchanged (no removal of materialized inherited entries observed).

Caveat: couldn't fully isolate "inherited-only entries" because the creator-rule auto-grants explicit _owner on every created entity, AND in this single-user probe the same person was both creator and parent owner. The two grants merge into one (no inherited: true flag), per the documented behavior. So this probe can't tell us whether the materialized-inherited entries would have been cleaned up after the flip, or persisted.

Case 2: Delete parent that has children inheriting from it

Parent deletion succeeded normally (HTTP 200). Children remained with _parent still pointing to the deleted entity ID (which now 404s). Children retained their explicit _owner (creator-rule grant).

So:

• Parent deletion is allowed even when children exist
• Children become orphans (referenced parent gone but _parent ref unchanged)
• Their own explicit _owner keeps them above the "can't delete last _owner" threshold

Cases that remain untested (would need a second person to probe cleanly)

The creator-rule means every entity gets an explicit _owner equal to the creator. With only one logged-in user, we can't simulate "child has _owner from parent inheritance only, no explicit _owner of its own."

Open empirical questions:

1. Does flipping _inheritrights to false remove materialized inherited _owner entries from the child? (Likely yes per the inherited: true flag semantics, but unconfirmed.)
2. If a child has ONLY inherited _owner entries and its parent gets deleted, does the child end up with zero _owner entries?
3. Same question with the _inheritrights flip — can an entity reach zero-_owner state by disabling inheritance?

The "can't delete last _owner" rule fires on direct DELETE of the property entry; it doesn't (apparently) guard against indirect removal via inheritance-source changes. Worth confirming and documenting:

• Either: clarify in the docs that zero-_owner state IS reachable via parent-delete or inheritrights-flip (so apps know to defend at app layer)
• Or: extend the platform safety to cover these cases (more invasive — would require re-evaluation logic on every inheritance source change)

Probed against api.entu.app/polyphony with Mihkel's session.