perf(tests): seed the loopback provider into starter templates instead of reloading (#14589)

`configureLoopbackOpenAI` patched the persisted flow behind the running editor
and then reloaded the page so the editor would pick the change up. Playwright
serves the app from a Vite dev server, so that reload replays ~3.5k unbundled
module requests: 19-35s on Windows CI, and it happens once per test across 38
call sites.

Nothing forces the configuration to arrive out of band. `useAddFlow` posts the
starter template the browser fetched from `/api/v1/flows/basic_examples/`, so
serving that catalog already pointed at the loopback fixture makes the flow
*born* configured — the editor and the database never diverge and there is
nothing to reload for.

`seedLoopbackProvider(page)` installs that route and must run before the first
navigation, since React Query caches the catalog for the session.
`configureLoopbackOpenAI` then takes a fast path when the flow it reads is
already configured, and keeps the patch-and-reload path otherwise, so a spec
that does not seed (or builds its flow from a blank canvas) is unaffected. The
fallback warns rather than staying silent, so the optimization cannot rot
unnoticed across the seeded specs.

The one thing that can still write these nodes without a reload is the model
refresh `useApplyFlowToCanvas` fires on mount, so the fast path waits for it.
Refreshes carry no flow in their URL — `buildRefreshPayload` stamps
`_frontend_node_flow_id` onto the template — so `modelRefreshFlowId` attributes
them, and the tracker is armed before navigation to avoid a retroactive wait.

The shared mutation and predicates move into `loopback-provider-policy.mjs`
alongside the existing `flow-editor-persistence-policy.mjs`, pure and unit
tested, so the route seeder and the patch path cannot drift apart.

Not rolled out to specs that build from a blank canvas (`decisionFlow`,
`similarity`, `Youtube Analysis`) — seeding the template catalog does nothing
for them. Deliberately opt-in rather than folded into `openStarterProject`:
`live/llm-provider-smoke.spec.ts` uses that helper and must reach a real
provider, which is exactly the failure mode #14540 fixed for the live config.

Measured locally on macOS, bulk-delete-sessions.spec.ts (8 tests, 2 workers):
2.8m before, 1.6m after, all passing both ways. macOS reloads are far cheaper
than the 19-35s measured on Windows, so the CI saving should be larger.