fix: two exact-shape assertions pinned the old schedule-status payload

B3 added failing_sources / no_access_sources to schedule-status and
broke test_schedule_status_shape and test_summary_returns_rollup_shape,
both of which assert the payload's EXACT key set. My own tests passed;
these two did not, and integration caught it.

A rule 90 miss: I grepped for the predicates I changed and not for
consumers of the response shape. The shape is the thing I actually
changed.

Both keys added to the assertions rather than loosening them to a
subset check — an exact-set assertion is what catches a key being
renamed out from under a consumer, which is precisely the value these
two tests just demonstrated.

The other readers (PipelineStatusChip, SchedulerStatusBar) pull
individual keys, so they were unaffected. SchedulerStatusBar's prop
comment documented the old shape and is corrected here; a comment that
lies about a contract is worth the same as a doc that does.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LNXXULQDjVZmbuNa2G9mD9

tests/test_api_sources.py

@@ -55,10 +55,16 @@ async def test_schedule_status_shape(client):
     body = await resp.get_json()
     assert set(body) == {
         "last_tick_at", "next_due_at", "due_now", "auto_sources",
+        "failing_sources", "no_access_sources",
         "platform_cooldowns",
     }
     assert isinstance(body["due_now"], int)
     assert isinstance(body["auto_sources"], int)
+    # #387 B3: the front-door ribbon reads these two. Kept in the exact-set
+    # assertion deliberately — it is what catches a key being renamed out from
+    # under a consumer, which is how this test earned its keep.
+    assert isinstance(body["failing_sources"], int)
+    assert isinstance(body["no_access_sources"], int)
 
 
 @pytest.mark.asyncio