perf(render): fix lazy-render and fold performance for large sessions

[jensenojs]

Problem

2786-message sessions take ~36 seconds to render. Two root causes:

1. set_folds() uses cursor() + normal! zc/zo per fold, each triggering a full-screen redraw (~90ms/fold × 392 folds)
2. _render_full_session_data() renders all messages on initial load

Closes #392

Changes

Fold performance (36s → 3s)

• Replace vim.fn.cursor() + normal! zc/zo with :{from},{to}fold and :{from},{to}foldopen! — Ex commands don't move the cursor, zero screen redraws
• Switch to foldmethod=manual before creating folds and stay there — prevents foldexpr recalculation for every buffer line (~4.6s on 87K lines)
• Add line count validation to prevent E16: Invalid range errors

Lazy render (3s → ~10ms)

• Only render enough messages to fill the output window on initial load (~1.5× viewport height)
• Load more on scroll-to-top via WinScrolled autocmd
• opts.lazy = true explicit opt-in — tests and headless environments render all messages
• Fix lazy_render_count being cleared by M.reset(): read before reset, persist back to ctx after determining limit
• Debounce WinScrolled load_more callback (150ms) to prevent rapid re-renders during fast scrolling
• Remove debug vim.notify logging from render paths

Performance

Phase	Before	After
Fold creation	~35,266ms	~0.8ms
Total render	~36,000ms	~10ms
E2E (incl. async fetch)	~36,000ms	~1,875ms

Measured on a 2786-msg / 87K-line session

Testing

7 new test cases in tests/unit/renderer_lazy_spec.lua:

• Renders all messages when lazy=false
• Renders limited messages when ctx.lazy_render_count is set
• Preserves lazy_render_count increment across render reset (exposes the core bug)
• load_more_messages increments rendered message count
• load_more_messages returns false when all/no messages loaded
• No INFO-level debug notifications during rendering

All 110 existing tests pass.

[sudo-tee]

Thanks for the PR.

I will have a look at soon, I will be out for the weekend. So I will look at it at the start of the next week

[jensenojs]

I want to go out and have fun too. Have a nice weekend!

[sudo-tee]

Awesome, I will do some testing on this throughout the day and let you know. Since this is a significant change in the rendering, I want to test it a little bit.

[sudo-tee]

@jensenojs

Thanks for the fix, while we are here can we set foldchars

  window_options.set_window_option('fillchars', 'fold:-,foldopen:-,foldclose:+,foldsep:│', windows.output_win)

otherwise we see the fold number which looks a bit odd

[sudo-tee]

I feel that we should combine the max_message behavior with the lazy one, otherwise it might make things confusing. And setting it to nil would essentially disable the lazy rendering ?

[jensenojs]

Sorry, I might be a bit busy these two days, and I actually lack some context in understanding the "max_message" feature. I can roughly grasp that the relationship between these two features might be a bit confusing, but I haven't figured it out yet.

For my simple profile, SQLite reading doesn't seem to be the bottleneck. I'll look into why that feature was introduced in the next day or two to make sure I haven't missed any considerations

[sudo-tee]

I did some initial test and it works well.

I do have some comments:

• When loading more with the line action the cursor is moved back to end of the window

Screen.Recording.2026-06-02.074248.mp4

• The config already expose a max_message and truncate the view, I feel we could combine the behaviors ? if not it might cause confision

Other than that it looks and feels good.

Thanks for your effort

[jensenojs]

lazy-render is no longer a user setting — it's always on. hidden_count only reflects max_messages truncation now.

Behavior changes:

• gg loads all messages before jumping to top (full history searchable)
• load_more preserves cursor position instead of jumping to bottom
• Search scope is rendered content (after gg or scrolling up = everything)
  Cursor bug: fixed.

@jemag would be great if you could test this branch — i am not sure if max_messages is still needed for performance on your setup. Rendering should be much faster now.