feat(tickets): deliver canonical operational lifecycle

docs/TICKETS_DOMAIN_BOUNDARY.md

@@ -59,20 +59,42 @@ service history; the case becomes authoritative for the formal procedure.
 The former Issue Reporting and Helpdesk concepts become ticket type, intake,
 queue, and policy profiles. They do not need separate persistence models.
 
-## Seed State
+## Implemented Vertical Slice
 
-The current repository state is intentionally small:
+Tickets is now a native authoritative operational store with:
 
-- module manifest and entry point
-- tenant-level permission definitions
-- manager and viewer role templates
-- documentation topic describing the module boundary
-- Gitea issue workflow templates
-- manifest contract test
+- tenant-isolated ticket identity and current state
+- replay-safe reporting and guarded revision mutations
+- distinct reporting, triage, assignment, resolution, and administration scopes
+- reporter, requester, assignee, and typed participant references
+- related-work and attachment references without copying owner-module content
+- internal and reporter-visible comments
+- immutable lifecycle history with actor, time, reason, revision, and request digest
+- soft deletion that removes ordinary discovery while retaining evidence
+- Search backfill, authorization rechecks, and event-driven index changes
+- bounded data-subject export with manual retention review
 
-No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.
+The `/tickets` WebUI and `/api/v1/tickets` routes expose this lifecycle. All
+mutations carry an expected revision and an idempotency key. Resolved and closed
+tickets require a resolution summary; reopening continues the same operational
+record.
 
-## First Implementation Slice
+## Optional Providers
 
-Define ticket identity, intake profiles, queues, triage, assignment,
-resolution, and stable escalation links to cases.
+Core contracts keep integrations optional and implementation-independent:
+
+- `tickets.routing` may supply a queue, service target, and routing explanation.
+  Without it, authorized users set queue and target manually.
+- `tickets.case_escalation` may create a replay-safe formal Case and return its
+  stable reference. Without it, the ticket can still be resolved but the
+  escalation action is unavailable.
+
+Cases owns every created Case and its procedure. Helpdesk owns service profiles,
+queue semantics, routing, and escalation-clock policy. Tickets stores only the
+applied queue/target facts and the stable Case relation.
+
+## Remaining Provider Work
+
+- Helpdesk-owned configurable service profiles and routing provider
+- Cases-owned concrete `tickets.case_escalation` provider
+- connector-owned external service-desk transport and governed synchronization