refactor(unocrm): one file per class in Presentation/MockData

CrmPageMocks.cs stacked the Dashboard, Pipeline and Leads mocks into one
file named after the folder rather than a type — the file every new mock
gets appended to. Each now lives in DashboardPageMockData.cs,
PipelinePageMockData.cs and LeadsPageMockData.cs, matching the two mocks
that already had their own file. Each keeps its three-line ForModel
partial, which exists only to reach that one mock's protected
model-taking constructor.

The old file's 34-line header carried the rules every feed-shaped mock
follows, including the one that exists to stop a future edit ("these
feeds are inline no-capture lambdas — do not deduplicate them into a
helper"). Copying it three times would drift, so it moves onto
ContactsPageMockData.cs — the mock it already named as the reference —
as a numbered recipe the siblings cite by cref. Only the page-specific
paragraphs travelled with their own mock: the activity-list comparison
to Dashboard, the plain-arrays LiveCharts constraint to Leads.
DealDetailPageMockData now states why it sits outside the recipe (no
feeds, so nothing for a SourceContext to do).

No behaviour change: the previews bind these by type, the SDK globs the
new files, and every code line is preserved apart from normalizing
[Uno.Extensions.Reactive.ReactiveBindable] to the unqualified form its
siblings already used.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Jen-Uno

studio/uno-crm/UnoCRM/Presentation/MockData/ContactsPageMockData.cs

@@ -1,5 +1,42 @@
 namespace UnoCRM.Presentation.MockData;
 
+// The recipe every mock in this folder follows.
+//
+// Presentation/MockData holds one design-time DataContext per page, for Hot Design / Studio.
+// ContactsPageMockData below is the reference: it is the mock whose populated preview provably
+// renders on a design surface, so its siblings are built to the same four rules. They are recorded
+// here once, and each sibling file points back at them.
+//
+// 1. The statics hand out the GENERATED ViewModel, never the record. Every page renders at least one
+//    FeedView, and a FeedView can only subscribe to a FEED — a plain list would never reach it. So
+//    each mock is [ReactiveBindable], and the ViewModel the analyzer emits for it creates, in its
+//    constructor, the SourceContext that makes those feeds pump and materializes them into bindable
+//    lists. A raw record has no context, so its feeds never emit and the preview comes out empty.
+//    Handing the FeedView the bare feed instead of the ViewModel was tried, and does not help.
+//
+// 2. Those statics are expression-bodied — a fresh instance per access, never a cached singleton. A
+//    generated ViewModel has a view-scoped lifecycle: its SourceContext is created with the instance
+//    and disposed when the hosting view unloads. A shared singleton can be built before the design
+//    host's dispatcher is ready, or be disposed after a previous preview render, leaving a dead
+//    context whose feeds never emit. One instance per access mirrors the runtime per-navigation
+//    lifecycle, so every preview render gets a live ViewModel.
+//
+// 3. Every static input is declared ABOVE the statics that construct instances. Static members
+//    initialize in textual order, and an instance initializer that reads a not-yet-assigned static
+//    field gets null with no exception at all.
+//
+// 4. And the load-bearing one: every feed is built by an INLINE lambda that CAPTURES NOTHING — it
+//    reads static seed data directly. A no-capture lambda's delegate is cached by the compiler, and
+//    the feed factories cache the feed they build against that delegate instance, so every instance
+//    of a mock shares ONE feed, created once. Routing these through a shared helper that hoisted the
+//    payload into a local minted a fresh delegate, and so a fresh feed, per mock instance — and
+//    those previews rendered their lists empty. Do not "deduplicate" these lambdas into a helper.
+//
+// A variant needs the generated ViewModel's model-taking constructor, which is protected, so each
+// file also carries a small partial on its ViewModel exposing a factory that reaches it.
+//
+// None of these is ever seeded from a page constructor — see those constructors for why.
+
 /// <summary>
 /// Design-time DataContext for <see cref="ContactsPage"/> in Hot Design / Studio. ContactsModel has
 /// reactive members the design surface can't pump, so the two-way filters and header counts are