Add scoped postbox template previews

docs/POSTBOX_CONCEPT.md

@@ -139,6 +139,19 @@ scope, such as a unit type, structure, or subtree. Postbox resolves a stable
 unit-specific address from the tenant, template revision, concrete unit,
 concrete function, and optional case/service context.
 
+Subtree scope is explicit about the Organizations structure and may restrict
+the hierarchical relation types used within that structure. It does not infer
+scope from the legacy `parent_id` when an administrator creates or revises a
+template. This prevents an administrative, reporting, and project hierarchy
+from being confused when they contain the same units.
+
+Before saving a draft, administrators can run a read-only impact preview. It
+uses the same scope, function matching, address rendering, and incumbent rules
+as materialization and reports ready targets, already materialized addresses,
+vacancies, collisions, cycles, depth limits, and ambiguous paths. The preview
+does not create a template, address, Postbox, or delivery. A large result is
+bounded in the UI while its aggregate counts remain visible.
+
 Addresses should be resolved lazily and idempotently rather than eagerly
 creating empty containers for every unit. They remain durable through vacancy
 and reassignment. A delivery snapshots the template revision and normalized
@@ -155,6 +168,10 @@ unified inbox views and keep other responsibilities separate. Grouping is a
 query projection only. It never merges source containers, messages, read or
 acknowledgement state, retention, encryption keys, or audit evidence.
 
+Grouping summaries calculate total and unread counts over the currently
+visible source Postboxes in one tenant-bounded query. Hidden sources retained
+for later reassignment do not leak counts into the projection.
+
 Every item and action continues to show the source function, unit, postbox,
 assignment/delegation context, and classification. Policy may require some
 postboxes to remain separate.