Migrated-host i2i: exit 27 reports a dialog that cannot be identified (no incident bundle, consent state untracked) #770

What happened

Running the migrated-host image e2e during v0.72.0 release prep:

GFLOW_CLI_E2E_PROFILE=ffroliva GFLOW_CLI_E2E_PROJECT=cec73a13-…
pytest -m e2e_image tests/e2e/test_migrated_host_e2e.py

test_e2e_t2i_runs_on_a_moved_account            PASSED
test_e2e_mcp_i2i_runs_on_the_migrated_host      FAILED

MediaUploadRejectedError (exit 27): migrated host: a dialog opened after the file
was chosen and no maseQ request left the page — most likely Flow's one-time
upload-terms confirmation (host=migrated)

Why the message's hypothesis does not fit

ffroliva has already accepted the one-time "Rights to use this image" dialog. So the
leading hypothesis in that message is wrong for this account.

That is not a defect in the message — it says "most likely", and the guard is a
conjunction detector, not a dialog identifier. It counts dialogs across the upload
window deliberately: the dialog's two buttons carry no ligature and no data attribute
(separable only by DOM order) and its copy is translated, so no anchor there satisfies the
locale-invariance rule. Its remediation already anticipates this case — "If you see a
different dialog instead (an error, a quota notice, a re-login), that is the one blocking
the upload."

All that is actually established: some dialog opened after the file was chosen, and no
maseQ request left the page.

This is not #719 shape B. That one sends maseQ (measured 8 675 B) and never receives
a reply. Here nothing left the page at all — a different signature.

Why we cannot say more

No incident bundle was written. Exit 27 / MediaUploadRejectedError is not in the
capture triggers, so there is no DOM dump, no screenshot, and no ligature inventory naming
what opened. The one run that could have told us produced nothing to read.

What would settle it

1. Add MediaUploadRejectedError to the incident-capture triggers (diagnostics.py) so
   this failure writes a bundle like other typed failures do. Small, and it makes every
   future occurrence self-diagnosing instead of requiring a bespoke re-run.
2. Spike: dump role, aria-*, the ligature inventory and the DOM subtree of every
   dialog present at the moment the guard fires, on a consented account. $0 — the upload
   never reaches a submit.
3. Re-run test_e2e_mcp_i2i_runs_on_the_migrated_host with that instrumentation.

Related, and probably the better fix

Per maintainer: the account's upload-consent state should be tracked in the data layer
rather than inferred from a failure. Today the only signal is a guess made at the moment an
upload fails, which is why this issue exists at all — a consented account and an unconsented
one produce the same message. Recording consent per account/profile would make the guard
deterministic: it could say "this account has consented, so the dialog that opened is
something else" instead of leading with a hypothesis that is wrong half the time. Tracked
separately; noted here because it is the root reason this failure is ambiguous.

Scope

Not a regression from v0.72.0. #692 shipped live-verified by its contributor on both CLI
and queued-MCP paths, and CLI t2i passed first-hand during this release's verification.
Recorded in docs/LIVE_VERIFICATION_v0.72.0.md under "NOT verified this cycle".

Refs #692, #719.