Root cause of 'Ctrl-b does nothing': home-manager was not switched, so the
binding built into the flake was never deployed (~/.config/fish lacked
heal-autosuggest and \cb; the built config had both). Activation needs the
home rebuild, not a system rebuild.
heal-autosuggest is now two-phase (set 0; repaint; set 1; repaint) to give
the reader a disabled-state repaint, which is what clears the wedged
in_flight_autosuggest_request per reader.rs update_autosuggestion. Matches
the manual cure (which had prompt cycles between off and on); the old
back-to-back toggle and the postexec hook did not. User chose the
session-preserving toggle over exec fish.
A/B in a live lagging shell: disabling fish_autosuggestion_enabled cures
the lag instantly, and re-enabling does NOT bring it back — the toggle
resets the wedged reader state. __autosuggestion_unwedge (fish_postexec)
now applies that reset after every command, at the moment TUIs exit.
Builtins only, invisible, respects a deliberate manual disable. Flight
recorder stays armed until the hook is proven in real use.
Also from this investigation: wedged-thread evidence (sampler attach
cures), lag-sample tool, flight recorder in the zellij fish wrapper.
Root cause (proven via live lag-triage capture + deterministic PTY repro):
fish latches feature flags from its startup env before config.fish runs, so
the existing no-query-term settings never applied to zellij-spawned shells.
With query-term on, fish queries the terminal after every command; one reply
zellij fails to relay permanently degrades that fish process's reader.
Subshells were immune (inherited the exported var), which is why the lag
always 'disappeared' when tested in a new shell.
Also adds the lag-triage/unlag/term-probe diagnostic toolkit used to find
this, and upstream_repro.py for filing the fish-shell bug.
Noah Masur