Parity gallery: honest populated-state coverage (10/34 surfaces differ)

Fixed & documented, not-just-marketed:
- HomeScreen now derives summary card from LocalDataManager.myResidences
  with VM fallback — populated PNG genuinely differs from empty.
- DocumentsScreen added same LocalDataManager fallback pattern + ambient
  subscription check (bypass SubscriptionHelper's singleton gate).
- ScreenshotTests.setUp seeds the global DataManager singleton from the
  fixture per variant (subscription/user/residences/tasks/docs/contractors/
  lookups). Unblocks screens that bypass LocalDataManager.

Honest coverage after all fixes: 10/34 surface-pairs genuinely differ
(home, profile, residences, contractors, all_tasks, task_templates_browser
in dark mode, etc.). The other 24 remain identical because their VMs
independently track state via APILayer.getXxx() calls that fail in
Robolectric — VM state stays Idle/Error, so gated "populated" branches
never render.

Root architectural fix needed (not landed here): every VM's xxxState
should mirror DataManager.xxx reactively instead of tracking API results
independently. That's a ~20-VM refactor tracked as follow-up in
docs/parity-gallery.md "Known limitations".

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

docs/parity-gallery.md

@@ -156,6 +156,26 @@ Written to the output on each regeneration — check the top of
 
 ## Known limitations
 
+- **Android populated-state coverage is partial (10/34 surfaces differ).** Screens
+  like `home`, `profile`, `residences`, `contractors`, `all_tasks` render truly
+  populated data. The other ~24 screens (`documents`, `complete_task`,
+  `feature_comparison`, `notification_preferences`, `manage_users`, every
+  `edit_*` / `add_*` / auth form) currently show **identical renders for
+  empty and populated fixtures**, because their ViewModels independently track
+  state via `APILayer.getXxx()` calls that fail with "Not authenticated" in
+  Robolectric — the VM state never transitions to `ApiResult.Success` so the
+  screen's "populated" branch never renders, even though `LocalDataManager`
+  and the global `DataManager` singleton are both seeded with the fixture.
+
+  **The architectural fix**: every VM's `xxxState` needs to mirror
+  `DataManager.xxx` reactively (e.g., `dataManager.documents.map { Success(it) }`)
+  instead of independently tracking the API call result. That's a
+  per-VM refactor across ~20 ViewModels; currently only `HomeScreen` and
+  `DocumentsScreen` have been patched to fall back to `LocalDataManager`
+  directly. Gallery viewers should treat a "same" row as indicating the
+  fixture didn't reach the screen, not that the screens genuinely render
+  identically.
+
 - **iOS populated-state coverage is partial**. Swift Views today instantiate
   their ViewModels via `@StateObject viewModel = FooViewModel()`; the
   ViewModels read `DataManagerObservable.shared` directly rather than