docs: add #292 entry to v0.8.0 CHANGELOG

CSS max-width / max-height / min-width / min-height on <img>
(closes #291). Pre-fix the CSS parser stored the values but the
converter never threaded them to ImageElement, and ImageElement
had no fields to receive them. Post-fix adds cssMax*/cssMin*
fields, SetMaxSize/SetMinSize setters, and an aspect-preserving
clamp helper applied before object-fit dispatch and after auto-
resolution. Container width remains the absolute outer bound for
replaced elements per CSS 2.1 §10.4.

This is the spec-completeness shape — same as #287 (numeric
font-weight), #288 (text-align: start/end), #289 (overline),
#290 (border 3D styles): a CSS spec value the parser stored but
the consumer-side primitive didn't read.

Author: carlos7ags

CHANGELOG.md

@@ -54,6 +54,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - **CSS `text-align: start | end` direction-relative keywords (CSS Text L4 §7.1)** — pre-fix `parseTextAlign` returned `(AlignLeft, ok=false)` for both, so the registry's Apply silently dropped the declaration: `<p style="direction: rtl; text-align: start">שלום</p>` rendered left-aligned despite the author asking for the RTL start edge. Post-fix the parser preserves the keyword on `computedStyle.TextAlignKeyword` and a new `resolveTextAlign(style)` helper late-binds the resolution against `style.Direction` at consumer time (so source-order interactions like `text-align: start; direction: rtl` resolve correctly regardless of declaration ordering). Same treatment for `text-align-last` via `resolveTextAlignLast`. New public `layout.Paragraph.Align()` getter exposed for test inspection (#288)
 - **CSS `text-decoration-line: overline` (CSS Text Decoration L4 §3.1)** — pre-fix `layout.TextDecoration` defined `Underline (1<<0)` and `Strikethrough (1<<1)` only; the third spec line type was silently dropped at parse time. `<p style="text-decoration: overline">x</p>` rendered plain. Post-fix `DecorationOverline = 1 << 2` joins the bitset, `parseTextDecoration` ORs it in for the `overline` keyword (combinations like `text-decoration: underline overline line-through` produce all three flags), and `drawDecorations` renders the stroke at `baselineY + ascent * 0.95` with `text-decoration-style` dispatch (solid / double / wavy / dashed / dotted) honoured. The `double` secondary stroke offsets DOWNWARD (toward text) so both lines stay inside the line box even at `line-height: 1`. Adjacent runs with mismatched decoration sets correctly mask the trailing-space extension to only their shared subset, fixing a latent bug surfaced by the new flag (#289)
 - **CSS border styles `groove | ridge | inset | outset` (CSS Backgrounds L3 §4.1)** — pre-fix the parser stored the keyword string but `buildBorder`'s switch matched 3 keywords + default-solid, so `<div style="border: 4px ridge silver">` parsed and stored "ridge" but rendered as a flat solid line. Post-fix the parser whitelist accepts the four 3D bevel styles and `buildBorderForSide(side, ...)` dispatches per-side via new `beveledColor` / `lightenColor` / `darkenColor` helpers (fixed 30% sRGB shift; CMYK adjusts K). Per CSS §4.1: groove/inset → top+left dark, bottom+right light (sunken); ridge/outset → opposite (raised). Folio renders a single solid stroke per side with side-modulated color rather than the strict spec's two-half-width split bevel — visually indistinguishable for thin borders, less pronounced bevel for thick ones (#290)
+- **CSS `max-width` / `max-height` / `min-width` / `min-height` on `<img>` (CSS 2.1 §10.7)** — pre-fix the CSS parser stored these properties on `computedStyle` but `html/converter_image.go::convertImage` never threaded them to `layout.ImageElement`, and `ImageElement` had no fields to receive them. So a 2000×500 source logo with `max-width: 180px` in a 540pt-wide page bled the entire header instead of clamping. Post-fix `layout.ImageElement` gains `cssMaxWidth` / `cssMaxHeight` / `cssMinWidth` / `cssMinHeight` fields plus `SetMaxSize(maxW, maxH)` and `SetMinSize(minW, minH)` setters; `resolveSize` applies the clamps in spec order (max first, then min, with min winning over max per the conflict rule), aspect-preserving on each axis. The `object-fit` branch's early-return path now applies the clamps before fitting, so `<img width=200 height=200 style="object-fit: cover; max-width: 50px">` correctly produces a 50×50 box with cover-fit content. The container width remains the absolute outer bound for replaced elements per §10.4 — a `min-height` that would push the image past the canvas is silently dropped to keep the image inside its containing block, matching browser behaviour. Percentage `max-width: 50%` still resolves to 0pt because the converter's CSS-to-points conversion passes `relativeTo=0`; pre-existing limitation tracked separately (#291, #292)
 
 ### Changed