fix(config): default cli_refresh_interval to 0 to prevent terminal auto-scroll fighting (#53636)

[Tranquil-Flow]

What

On touch/auto-scroll terminals (Termux, Xshell, iTerm2, Windows Terminal), the
classic CLI viewport snaps back to the bottom every second because
display.cli_refresh_interval defaults to 1.0, which makes prompt_toolkit
redraw the UI on a 1s cadence. Each redraw repositions the cursor to the prompt
line and the terminal follows — making it impossible to scroll up and read past
output (#53636, #48309).

This flips the default to 0.0 so periodic background redraws are off
out-of-the-box. cli.py already passes refresh_interval= through with a
.get(..., 0) fallback, so this aligns the DEFAULT_CONFIG with the value
cli.py already implies.

Trade-off

A refresh interval of 0 means the idle status-bar wall clock will no longer
tick on its own during pure idle (no input/output). This is the regression side
of #45592, which had set the default to 1.0 to keep the status-bar read-out
alive. Users who want the ticking clock can re-enable it in their config.yaml:

display:
  cli_refresh_interval: 1.0

The severity asymmetry favors the new default: a frozen clock is cosmetic, while
a viewport that cannot be scrolled is a hard UX breakage on the affected
terminals. The status bar still renders correctly on every input and agent
output event.

How verified

• RED: changed the test to assert the new default and ran it against
  unmodified upstream/main → assert 1.0 == 0 failed (bug confirmed present).
• GREEN: applied the default change → test passes; full test_config.py
  suite (113 tests) passes.
• Exactly one focused commit ahead of upstream/main.

Test

Updates the existing TestCliRefreshIntervalConfig test to assert the new
default and documents the trade-off in the docstring.

Auto-published by Moonsong via Path B automated pipeline.

[alt-glitch]

This was generated by AI during triage.

Related: #53636 (the issue this fixes), #49056 (merged salvage that made display.cli_refresh_interval configurable but left the shipped default at 1.0), and #48309 (the original Xshell/iTerm2/Windows Terminal report). Verified on main: config.py DEFAULT_CONFIG still has cli_refresh_interval: 1.0, so the snap-back persists out-of-box for anyone who hasn't manually set it to 0 -- this PR is the residual default flip, not a duplicate. Note the documented trade-off: the idle status-bar wall clock stops ticking on pure idle, opt-in restorable in config.yaml.

[teknium1]

Thanks for the focused default change. The current classic CLI still passes display.cli_refresh_interval into Application(refresh_interval=...) at cli.py:15052, and main still defaults it to 1.0 at hermes_cli/config.py:1854, so the reported behavior remains actionable.

Problems

• This changes only the schema default. Existing raw display.cli_refresh_interval: 1.0 values still override it via _deep_merge (hermes_cli/config.py:6953-6967), and save_config preserves explicit raw paths (hermes_cli/config.py:7164-7201). Please avoid implying that every existing install changes automatically.
• The changed test only checks the DEFAULT_CONFIG literal. It does not cover effective config resolution.

Suggested changes

• Add temporary-HERMES_HOME tests showing an absent persisted key resolves to 0, while an explicit 1.0 remains preserved.
• State that users with an explicit existing value can use hermes config set display.cli_refresh_interval 0.

Automated hermes-sweeper review.