45c5ff8234
nav_to_flight.sh contains no run-canary invocation -- it drives an already-running emulator -- so whether a profile is signed in depends entirely on how the caller launched it. Every nav_to_flight run in this session was launched with a bare run-canary, which is why they froze. Worth stating plainly because the script prints "signing in profile B13EBABEBABEBABE", which comes from the emulator's startup rather than from the script arranging it. Refuted: "each screen loads its own GP_*.pak", a plausible route to a real screen identity. With full file logging the only names that appear are at boot (sound.p0x, tables.p00, hidden) and nothing new opens as the UI moves between screens -- the paks are opened once and read by offset, so file I/O carries no per-screen signal. Also recorded: one launch this iteration never reached the title -- progress counter stuck at 0, black screen, guest churn 0.001%. That is a DIFFERENT failure from the sign-in freeze, which stalls after the main menu with the counters already advanced, and it matches the boot flakiness canary-scripted-input-traps.md already documents. The counters distinguish them: sign-in freeze stalls past the title, a bad boot never leaves 0.