[BUG] pptx HTML preview: line box is constant at the root font size (`.para { line-height: 1 }` without font-size) — preview overflow is unreliable; `view issues` misses real overflows

## Summary

The HTML preview (`view html` / `watch` / `screenshot`) renders every text line with a **constant line box equal to the root font size**, regardless of the run's actual font size. Root cause: the generated stylesheet sets `.para { line-height: 1 }`, but `.para` itself has no `font-size` (font size lives on the inner ``), so `line-height: 1` resolves against the **inherited root font size** (18pt in my decks).

Measured on v1.0.136: runs at 6.5pt / 7pt / 7.5pt / 8.5pt all produce a line box of exactly 18.0pt.

Real PowerPoint single spacing is ≈ **1.32 × the run's font size** (per the font's hhea metrics; measured with Microsoft YaHei). Two consequences:

1. **Small text**: preview line boxes are far taller than PowerPoint's → text that fits fine in PowerPoint appears clipped/overflowing in the preview. In one deck a re-check reported 64 "overflows" that were all preview artifacts.
2. **Large text**: a 15pt+ line gets an 18pt box (less than 1.32×15 ≈ 19.8pt) → the preview can *understate* the height, so "fits in preview" is only a conservative proxy in one direction and inverts for sizes above root/1.32.

## Related: `view issues` overflow detection

`view issues` appears to estimate text height with line-height 1.0, which makes it *miss* real overflows — I have repeatedly had it report "no overflow" on slides where PowerPoint visibly clips the text.

## Repro sketch

```bash
officecli view deck.pptx html -o out.html
grep -o 'line-height:[^;}]*' out.html | sort | uniq -c # -> "line-height: 1" on .para
grep -oE '\.para\s*\{[^}]*\}' out.html # -> no font-size on .para
```

Then measure any rendered line's box height in a browser: it equals the root font size for every run size.

## Expected

Either move the effective font size onto the element that carries `line-height`, or compute line boxes as `k × run font size` with k ≈ 1.2–1.32 (PowerPoint's effective single-spacing factor), and use the same metric in `view issues` overflow estimation.

Start by reproducing the issue with `officecli view deck.pptx html -o out.html`, `grep` the generated `.para` rule, and compare rendered line boxes for the listed run sizes. Trace the HTML preview and `view issues` overflow estimation, then verify that both use the run’s effective line-height metric and no longer produce the reported false results.

Written by the indexing model from the issue text.