bug: locale resolution is blind on flow.google.com and DEMOTES a learned locale (measured en + pt-BR) #643

Summary

On Flow's migrated flow.google.com origin, locale resolution is structurally blind — and worse, it demotes a correctly-learned locale on every migrated page load.

Measured 2026-09-03 on two profiles, read-only, zero credits.

The measurement

Root cause

routes.py:180:

LOCALE_SEGMENT_RE = re.compile(r"^https://labs\.google/fx/([a-z]{2,3})(?:-[A-Za-z]{2})?/tools/flow")

The migrated URL is /project/<id> — it drops /fx/<locale>/tools/flow entirely, so this can never match. The locale did not disappear; it moved from the URL into the document (html lang=pt is still correct on the migrated host).

Two consequences, both measured

1. It demotes a known-good locale. next_locale_state("pt", None) returned "?" (PROVISIONAL) — measured, not inferred. Every migrated load discards denon82's learned pt. Not a correctness break (bare URLs are documented as "never worse"), but on a fully-migrated account the locale can never be learned again, silently undoing #587.

2. Four seconds wasted per navigation. await_url_settled burns the full URL_SETTLE_TIMEOUT_MS waiting for a shape that can no longer exist. This lands on top of the ~8 s detect_ui_mode window and ~24 s crop cascade already spent before a migrated run fails.

Suggested fix

Fall back to document.documentElement.lang when the URL carries no segment. The probe data validates it as trustworthy: html lang agreed with the URL segment wherever both existed (pt/pt, en/en). Unlike navigator.language — which locale_segment_from_url's docstring correctly warns reports the value gflow itself sets — html lang is server-rendered by Flow.

Also worth short-circuiting await_url_settled when flow_host_kind(page.url) == "migrated", so the 4 s is not spent waiting for an impossible shape.

Refs #639