Invalidate display after fzf history search, forcing a refresh

[rolandwalker]

Description

Depending upon settings, the prompt message might be invisible after returning from an fzf search. One cause could be

export FZF_DEFAULT_OPTS='--height=15%'

Leaving aside the question of the interaction between the environment variable and the search interface expected by the mycli documentation, we can solve the issue of the lost prompt message by manually invalidating the display.

As the docstring notes, app.invalidate() did not have the desired effect, and caused warnings at exit time:

Task was destroyed but it is pending!

While this is more general, it is related to #1630 , which ensures that the above specific --height=15% issue is resolved in a specific way.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[github-actions]

Findings

1. Potential behavior regression: safe_invalidate_display prints an empty string via app.print_text(''), which still emits a newline. That means every fzf history search could add a blank line to the terminal output (visible in scrollback and possibly in logs). Was this intended? If not, consider a refresh that doesn’t write output (e.g., a no-op run_in_terminal plus app.invalidate() or another prompt_toolkit-supported refresh call).
   mycli/packages/toolkit/utils.py

2. Missing test coverage: there’s no test that validates the post-fzf refresh behavior or at least asserts no extra blank line is produced. Even a minimal unit test around safe_invalidate_display (or an integration test in the toolkit tests if available) would guard against regressions.
   mycli/packages/toolkit/fzf.py, mycli/packages/toolkit/utils.py

Notes

• No security concerns spotted in the diff.

If you want, I can draft a small test or propose a refresh approach that avoids writing output.