less -R search highlight bleeds across line wraps with ANSI-colored input

Symptom

When viewing ANSI-colored output through less -R, a search match that falls near the terminal's right margin causes the reverse-video highlight (SGR 7) to extend past the matched text onto the following wrapped line. The bleed persists until another SGR reset sequence appears in the stream.

Context

The -R option passes ANSI SGR sequences through while filtering most other control characters. Search highlighting adds its own SGR 7 sequence around each match. If a match spans a soft wrap, less does not automatically emit an SGR 0 reset at the wrap boundary; the highlight therefore continues into the next visual line. Terminal emulators differ in whether they treat SGR attributes as line-local or global, so the visible effect varies across xterm, vte, Windows Terminal, and iTerm2.

Since less 551 the --use-color flag makes SGR 7 the default highlight, but the wrap behavior is unchanged. Users can override the highlight sequence via LESS_TERMCAP_* variables, yet no terminfo capability expresses “reset at wrap”.

Open questions

1. Is the missing wrap reset a deliberate design choice or an oversight in the line-folding logic?
2. Can a terminfo capability (e.g., an extended sgr0 variant) be defined to force a reset at each virtual line boundary without patching less?
3. Would a new option such as --highlight-wrap-reset be accepted upstream, or is the fix expected to live in terminal emulators?