Advance the reactor once per sleepy room when resuming update task

`test_background_update_room_membership_resume_after_restart` now leaves two
rooms (`room_id_2` and `room_id_3`) for the resumed task to update, where
upstream's version of this test only left one.

`Clock.advance()` moves its clock forward *first* and then drains only the
calls that are already due, so the `clock.sleep(...)` that
`potentially_slow_update_membership` schedules while an advance is draining
lands past that advance's target time and does not fire. One advance therefore
only gets the resumed task as far as `room_id_2`, leaving `room_id_3` on the
old display name.

Step the clock once per remaining room so both updates run.

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

tests/handlers/test_profile.py

@@ -827,10 +827,15 @@ class ProfileTestCase(unittest.HomeserverTestCase):
                 )
             )
 
-            # Wait for the `TaskScheduler.SCHEDULE_INTERVAL`
+            # Wait for the `TaskScheduler.SCHEDULE_INTERVAL` so the task is relaunched
             self.reactor.advance(Duration(minutes=1).as_secs())
-            # Let's be sure we are over the delay introduced by slow_update_membership
-            self.reactor.advance(Duration(milliseconds=20).as_secs())
+
+            # The resumed task still has `room_id_2` and `room_id_3` to update, and
+            # `potentially_slow_update_membership` sleeps for each of them. A sleep
+            # scheduled *during* a `reactor.advance(...)` is queued past that advance's
+            # target time, so each one needs an advance of its own to fire.
+            for _ in (room_id_2, room_id_3):
+                self.reactor.advance(Duration(milliseconds=20).as_secs())
 
             # Updates should have been resumed from room 2 after the restart
             # so room 1 should not have been updated this time