docs(aggregate): record MCP filter-parity footnote post-slice-D

docs/plans/aggregator-refactor.md

@@ -214,6 +214,36 @@ Unit tests in `internal/aggregate/` use in-memory stub implementations of
 Integration coverage stays in `web/...` and `mcp/...` and continues to
 exercise the real wiring through the Slice B/C/D ports.
 
+## MCP filter-parity note (post-slice-D, 2026-05-22)
+
+Slice D moved MCP item resolution from `web.TreeFilter` to
+`store.ListByFilters`. The dimensions that round-trip identically:
+
+- `tags` — AND-match, unchanged.
+- `q` — substring match, unchanged.
+- `kinds` — unchanged (drives `aggregate.AllOpts.Kinds`).
+- `from`/`to`/`order` — unchanged.
+- `has` — explicit in-memory narrow against
+  `store.LinksByRefType` (caldav-list / gitea-repo only).
+- `include_excluded` — explicit in-memory filter against each item's
+  `timeline_exclude` array.
+
+Narrowed dimensions in the MCP path (vs. web TreeFilter):
+
+- `status` — first value wins (single-value at the store layer).
+  TreeFilter accepts multiple. Use case is rare — most calls default
+  to `["active"]`.
+- `mgmt` — AND-match (item must carry every named mode). TreeFilter
+  used OR semantics including a synthetic `"unmanaged"` matcher.
+  Reachable workaround: omit `mgmt` and filter the returned items
+  client-side.
+
+Not a regression worth fixing in 5a — every documented MCP call from
+m and from otto-PWA uses tag + default status. If the gap bites, the
+fix is to either teach `store.ListByFilters` to accept multi-value
+status / OR-mgmt, or to lift `TreeFilter` into a neutral package and
+call it from both web/ and mcp/.
+
 ## Future work (out of scope for 5a)
 
 - Banner-surfacing for upstream failures (calendar unreachable, repo