view issues almost replaces whole-document HTML previews for automated audits — two gaps: xlsx numeric-fit (###) and pptx layout/spacing checks

## Summary

LLM-driven callers (we embed OfficeCLI in MemVerge/MemBox) audit every generated
document before delivering it. The audit needs machine-checkable findings, and
`view issues` is exactly the right surface: short, and every finding
carries a path and a suggested fix.

Today two families of checks are not in `ViewAsIssues`, which forces callers to
fall back on whole-document `view html` dumps. Those are token-expensive for an
LLM caller and get truncated by output caps — and for the most important xlsx
check the fallback does not even work (details below). Both gaps are arithmetic
on data the handlers already parse.

Measured with the v1.0.143 release binary on `examples/budget_review_v2.pptx`
(8 slides):

| Mode | Bytes |
|---|---:|
| `view html` | 107,875 |
| `view annotated` | 4,761 |
| `view issues` | 1,465 (13 findings, each with a path + suggested fix) |
| `view outline` | 434 |

Our runtime caps tool output at 64 KiB per stream, so the HTML "ground truth"
arrives truncated at real document sizes; `view issues` is both ~70× smaller and
more actionable.

## Version

- Behavior measured on the `v1.0.143` release binary (macOS arm64).
- Source line references are from `main` at `459b1a47`.

## Part 1 — xlsx: a numeric-fit (`###`) check in `ViewAsIssues`

`###` is the highest-signal rendering defect in a delivered workbook: Excel
shows it whenever a numeric or date column is too narrow for its formatted
value. Today no OfficeCLI surface can detect it:

1. OfficeCLI never emits `###` — it is an Excel rendering behavior, not file
content.
2. The HTML preview deliberately does not emulate it. `GetSpillWidthPt`
reproduces Excel's *text* behavior only — spill across empty neighbours and
shrink-to-fit — and bails on numbers explicitly:
*"(a) Must be text/general — NOT a number and NOT a numeric formula result.
Excel right-aligns numbers and never spills them."*
(`src/officecli/Handlers/Excel/ExcelHandler.HtmlPreview.cs`, ~line 988)
3. `CheckAllCellOverflow` skips it by design: *"Skips overflow-right on
non-wrapText cells — that is Excel's normal rendering, not a bug"*
(`src/officecli/Handlers/Excel/ExcelHandler.CheckOverflow.cs`, header
comment). Correct for text, which spills; wrong for numbers, which render
as `###`.

So an automated caller reading the HTML preview is scanning for a marker that
is never present.

**The pieces already exist.** The renderer holds per-column widths in points
(`SheetRenderContext.ColWidths`) and a glyph-advance text-width model —
*"chars × fontPt × 0.62"* — used by both the spill and shrink-to-fit paths
(`ExcelHandler.HtmlPreview.cs`, ~line 1044). A numeric-fit check is the same
comparison with spill disallowed:

> for each numeric/date cell: if formatted-value width (glyph model) >
> column width and the cell is not shrinkToFit → report.

Suggested finding shape, matching the existing issues format:

```
[N1] /Sheet1/H7: numeric overflow: '1,234,567.00' at 11.0pt needs 14.2 width, col H is 8.43. suggest.width=15
```

## Part 2 — pptx: layout/spacing checks in `ViewAsIssues`

`PowerPointHandler.ViewAsIssues` (`PowerPointHandler.View.cs`, ~line 515)
already computes the hard geometry checks — text overflow (`CheckTextOverflow`),
off-slide shapes with cm distances, occlusion (text ≥20% covered by a later
opaque shape), low contrast (fill <30% brightness with text <80%), table
row/grid mismatches. That is most of a professional deck audit already.

The remaining checks a deck audit needs are all arithmetic on coordinates and
text the handler already parses per shape:

- **narrow text box** — content fits but wraps to many short lines
(wrap-line-count estimate from the existing text-width model).
- **tight margin** — element closer than ~0.5" to a slide edge (the off-slide
check already computes edge distances; this is the same math with a positive
threshold).
- **tight gap** — two sibling boxes closer than ~0.3".
- **uneven gaps** — one large empty region while another side is cramped
(variance over the gaps between siblings on the same axis).
- **column / repeat-element misalignment** — shapes that look like a row/column
of cards but are off baseline or of inconsistent width beyond a tolerance.
- **missing arrowheads** — connectors between shapes with no head/tail end
decoration (reads as a plain line in a flowchart).
- **decorative-line / title mismatch** — an accent bar sized for a one-line
title under a title that wrapped to two lines (or vice versa).
- **footer / citation collision** — footer, source line or page number whose
box intersects content above it (the occlusion pass already does rectangle
intersection).

Thresholds could ship as defaults (possibly at a distinct severity, or behind
`--issue-type layout`) so existing consumers of `view issues` are unaffected.

## Why this matters upstream rather than just to us

Any automated or LLM-driven consumer of OfficeCLI has the same shape of
problem: `view html` is the only whole-document render, it is large, and it is
the only place several of these defects are (partially) visible. Moving the
checks into `view issues` makes them cheaper, deterministic, and available to
every caller — and each finding arrives with a path and a suggested fix in the
format `view issues` already established.

Context: MemVerge/MemBox#2880 (token-amplification report that surfaced this)
and MemVerge/MemBox#2909 (our side: the audit gates now drive on
`view issues` + `annotated` + `get`; we kept the docx HTML-preview gate because
docx `ViewAsIssues` currently reports only empty-paragraph / first-line-indent /
consecutive-spaces findings — a richer docx `view issues` would let us drop
that one too, but the xlsx and pptx parts above are the high-payoff pieces).

Happy to split this into two issues (xlsx / pptx) if that fits your tracker
better.

Start with src/officecli/Handlers/Excel/ExcelHandler.HtmlPreview.cs and ExcelHandler.CheckOverflow.cs to understand the existing width model and overflow behavior. Then read PowerPointHandler.View.cs around ViewAsIssues and its existing geometry checks. Done means ViewAsIssues emits path-based, suggested-fix findings for the requested numeric-fit and layout/spacing cases without changing existing consumers by default.

Written by the indexing model from the issue text.