fix(tests): measure the flow persistence barrier from the reload, not before it (#14587)

Windows Playwright shards 30/70 and 31/70 were the only failing jobs in nightly
run 31867911970; all 70 Linux shards passed, including the Linux shards running
the same spec. Five of bulk-delete-sessions.spec.ts's fourteen tests failed with

    Flow <uuid> did not finish model refresh and autosave persistence within 30000ms

reloadAndWaitForFlowPersistence created its deadline setTimeout before calling
page.reload(), so the 30s budget had to cover the page load as well as the
model refresh and autosave it is actually there to observe. Playwright serves
the editor from a Vite dev server (`npm start`), so a reload replays ~3.5k
unbundled module requests. Measured from the blob-report traces on Windows:

    trace      page.reload()   GET /flows/{id}   POST custom_component/update
    e3fe6e22        19.0s           t+27.6s          t+29.7s (1.06s)
    1a49b9dd        21.5s           t+28.9s          t+47.5s (10.8s)
    f6f421a4        34.9s              --                 --

The third reload outlasts the whole budget on its own, so that run could never
pass. Arm the deadline after the reload resolves and raise it to TIMEOUTS.long;
the worst observed post-reload cost was ~37s, and the test timeout is 5min
while these tests run 65-95s.

The barrier reaches 38 call sites across 30 spec files, so this was a latent
flake for every Windows spec that configures the loopback provider, not just
the two shards that happened to pair two playground chat builds on one runner.