fix(tmux): reset captured SGR before live output resumes

[ludovicfourrage]

Fixes #629.

Full-history pane captures can end with a nested tmux status bar's SGR still active, making later text and erase-to-end inherit its background. Reset SGR after replayed content and before cursor restoration. Apply the same reset to both raw-capture fallbacks, including the visible path identified in the issue reply. Empty captures retain the empty-string sentinel so callers keep their recorded history.

Adds unit tests exercising the real capturePaneBuffer with mocked tmux IO, plus a Chromium regression using the installed xterm.js. All three affected branches preserve the green status bar while subsequent text and erased cells use the default background. Registers the browser test in the dedicated runner.

Validation:

• Before the fix: all three style unit assertions and all three browser cases failed for the missing reset / inherited background.
• After the fix: 135 focused tests pass across five files; all three Chromium cases pass.
• Typecheck, lint, scoped Prettier checks, browser-suite exclusion check, and git diff --check pass.
• Fresh-eyes review completed; empty-capture edge case covered.

[Ark0N]

Merged and shipped in 1.42.0, closing #629. Thanks @ludovicfourrage, and welcome as a first-time contributor!

A very precise first PR: the tests drive the real capturePaneBuffer and a real xterm, fail on master and pass with the fix, and you covered the visible-path fallback from the issue thread too. The PR's CI never ran (first-time contributor workflows wait for approval), so I ran every CI step on the branch here: typecheck, lint, format, the lockfile and browser-exclude checks, the unit tests and npm run test:browser -- test/tmux-capture-sgr.browser.test.ts, all green. I also checked the CLAUDE.md rule for full-history captures: the reset goes before the relative cursor move back to the caret, so the capture still ends the way the client expects.