fix: `style: "auto"` always renders markdown dark, ignoring terminal background

Problem/Goal

In glow 3.0.0, auto resolves to dark for every markdown file, whatever the terminal reports. On a light terminal the result is light-grey text on a light background.

utils/utils.go:73:

func GlamourStyle(style string, isCode bool) glamour.TermRendererOption {
	if !isCode {
		if style == "auto" {
			return glamour.WithStandardStyle("dark")   // ← markdown: always dark
		}

The detection exists ten lines below, but only on the isCode path:

	case "auto":
		if lipgloss.HasDarkBackground(os.Stdin, os.Stdout) {

Markdown files are !isCode, so the terminal's reply is never consulted.

Regression in 3.0.0, introduced migrating to glamour v2, which removed auto-style (glamour#410) and moved the query to Lip Gloss. Only one of the two paths was updated.

Implementation Guidance

Resolve auto through lipgloss.HasDarkBackground on the !isCode path too. Cache the result — GlamourStyle is called once per rendered document (ui/pager.go:368), and querying the terminal on every render would interfere with the TUI's input handling.

Acceptance Criteria

• glow file.md with style: auto renders the light theme on a light terminal and the dark theme on a dark one.
• Output matches -s light / -s dark respectively.
• dark remains the fallback when the terminal does not answer.
• Explicit -s light / -s dark unchanged.
• The terminal is queried at most once per process.

Reproduction

Terminal-independent, using a pty that answers OSC 11 with a light background:

stock 3.0.0  auto + terminal reports LIGHT   → 38;5;252  (dark theme)
stock 3.0.0  auto + terminal silent          → 38;5;252  (dark theme)
reference    -s light                        → 38;5;234
reference    -s dark                         → 38;5;252

Identical output whether the terminal reports light, dark, or nothing.

Verified separately that terminals do answer: Ghostty replies rgb:efef/f1f1/f5f5 to ESC]11;?.

Notes

Also reported in #1020 (closed as a duplicate of a PR that does not appear to exist), a comment on #1007, and #877 (same failure, reported only under tmux).