feat(cases): accept replay-safe ticket escalations

docs/CONCEPT.md

@@ -90,6 +90,7 @@ The persistent backend provides:
 - tenant-level resource ACL and tenant summary providers
 - tenant-wide or restricted object access with explicit, revisioned grants
 - deterministic, replay-safe case launch from an exact Service binding
+- deterministic, replay-safe Case escalation from an authorized Ticket handoff
 
 The `/cases` list and `/cases/:caseId` detail workspace provide server-side
 search/status filtering, case facts, typed references, history, timeline, and
@@ -159,6 +160,15 @@ reference. Retrying the same launch returns the existing case; a changed request
 cannot reuse the key. Portal therefore cannot create duplicate cases after an
 ambiguous network response and does not gain access to Cases tables.
 
+`tickets.case_escalation` is the optional effect boundary used by Tickets. It
+rechecks `cases:case:create`, tenant identity, and the requested active Case
+type, then derives a stable Case identifier from the Ticket and idempotency key.
+The Case stores a governed `work_item` reference plus bounded source and handoff
+metadata. It never imports Tickets or copies Ticket messages, files,
+participants, assignment, or lifecycle. Replaying the same handoff returns the
+existing Case, while an unavailable Cases capability leaves the operational
+Ticket intact.
+
 Cases links formal Decision records and may retain a current outcome/status
 projection. It does not own decision authority, rule versions, reasoning,
 correction, revocation, or remedy semantics.