docs(07): mark deep-review blockers BL-01/BL-02 resolved (53c3ca5); verification addendum

.planning/phases/07-mobile-test-harness/07-REVIEW.md

@@ -18,11 +18,12 @@ files_reviewed_list:
 findings:
   critical: 0
   critical_resolved: 1
-  blocker: 2
+  blocker: 0
+  blocker_resolved: 2
   warning: 7
   info: 5
   total: 14
-status: issues_found
+status: blockers_resolved
 ---
 
 # Phase 7: Code Review Report (DEEP)
@@ -98,6 +99,20 @@ in README §"What globalSetup Does"; flagged only so it is not mistaken for broa
 
 ## Blocker Findings (NEW — surfaced by call-chain analysis)
 
+> **BOTH BLOCKERS RESOLVED in commit `53c3ca5`.**
+> - **BL-01:** the dead-`EmptyState` / always-rendered-wrapper assertions were replaced with a real
+>   DB→UI proof — `getByText('Seeded Test Event')` must be visible in the grid. Verified non-vacuous:
+>   passes with the seed on both profiles; with `/api/events` mocked to `[]` the title is absent
+>   (the assertion would fail). The old `'Nothing here'` check was empirically confirmed dead
+>   (count 0 even with zero events).
+> - **BL-02:** the reviewer's stated *mechanism* was inaccurate — the fetch window
+>   `[monthStart−7d, monthEnd+7d]` (verified in `calendarStore.initialCalendarRange`) **does** include
+>   `now+24h`, so the API window never excludes it. The real fragility is the rendered **month-agenda
+>   view of the current month** (both profiles are phone-width): on a month's last day "tomorrow" is in
+>   the next month and not displayed. The *conclusion* (a date-fragile visibility assertion) was correct.
+>   Fixed by re-anchoring the seed to **noon-today (UTC)** — always today's local date, always in the
+>   current-month view.
+
 ### BL-01: `calendar.spec.ts` populated-state assertions are vacuous — they cannot fail if the seed regresses
 
 **Files:**