docs(design-view): parent visibility = descendant-derived OR own membership

Untagged folder carrying its own FX/media shows in Arrange (its default) as
well as any mode derived from its children. Parents still never parked.

docs/product/design-view.md

@@ -90,10 +90,17 @@ home for untagged leaves — structurally it is just another mode.
   elsewhere. Untagged = Arrange.
 - **Leaves opt in.** You tag a *leaf* track into Design (or any mode). You never
   tag a parent.
-- **Parents are derived, never tagged.** A folder/parent track appears in — and is
-  never parked in — every mode that *any* of its descendant leaves belongs to. If
-  a folder holds two Design leaves and one Arrange leaf, the folder shows in both
-  modes. Rule of thumb: **tag leaves; parents follow.**
+- **Parents are derived, never tagged.** A folder/parent track's visibility is the
+  **OR of two sources**: (a) *descendant-derived* — it appears in every mode that
+  *any* of its descendant leaves belongs to; **or** (b) *its own membership* — an
+  untagged parent is an Arrange member by default, exactly like a leaf. If a folder
+  holds two Design leaves and one Arrange leaf, the folder shows in both modes by
+  descendant derivation. The case own-membership fixes: an **untagged folder that
+  carries its own FX/media** above leaves that are *all* tagged Design still shows in
+  **Arrange** (its own default) as well as Design (derived from its children) —
+  without the own-membership clause it would vanish from Arrange even though the
+  folder itself is an Arrange member. A parent is **never parked** in any mode it is
+  visible in. Rule of thumb: **tag leaves; parents follow** — still the common case.
 - **Master is always visible**, in every mode, and the tool never touches its
   flags. (REAPER's own SDK forbids driving `B_SHOWINTCP`/`B_SHOWINMIXER` on the
   master track — the invariant and the API agree.)
@@ -101,10 +108,11 @@ home for untagged leaves — structurally it is just another mode.
   mode only via (a) the explicit *show-both* toggle, or (b) the parent-derivation
   rule above. Otherwise a leaf lives in exactly one mode.
 
-The parent-derivation rule is why the pure model must be **folder-tree aware**. It
-cannot answer "should this parent be visible in mode M?" from the membership index
-alone — it needs the current parent↔child structure, which the shell reads from
-REAPER's `I_FOLDERDEPTH` and feeds in. The tree is an *input* to the pure model's
+The descendant-derived half of the parent rule is why the pure model must be
+**folder-tree aware**. Own-membership (part b) is answerable from the membership
+index alone, but descendant derivation (part a) is not — to know whether *any* child
+leaf is visible in mode M, the model needs the current parent↔child structure, which
+the shell reads from REAPER's `I_FOLDERDEPTH` and feeds in. The tree is an *input* to the pure model's
 visibility query, not something the model stores (folder structure is REAPER's
 truth and changes underneath us).