fix: support non-16:9 custom templates (4:3 etc.) and fix two pre-existing live preview issues

[ShotaroKataoka]

Fixes #208

Summary

Fixes layout breakage with custom templates whose slide size is not 16:9 (e.g. 4:3).
Also resolves two pre-existing live-preview problems that surfaced while working on it.

Background: this is not a new coordinate system, it is an alignment fix

The engine's px coordinate system already had a correct basis — 1920 px fixed
width, height following the aspect ratio — implemented in builder and
converter (EMU_PER_PX = slide_width / 1920). A 4:3 template's real canvas is
therefore 1920×1440 px.

The problem was that every other layer hardcoded a height of 1080. So this PR
does not introduce a new coordinate system; it aligns the remaining layers with
the basis that already existed.

Symptom in the issue	Root cause
Content sits at the top, large empty area at the bottom (main symptom)	Knowledge layer. references/ teaches "canvas is 1920×1080, drawing area y=173–950", so the model never designs below y=1080
Elements that fit are reported as out-of-bounds	Hardcoded height bound in lint
Element positions drift from template placeholders	analyzer converted to px with a fixed emu=6350 (reporting 1440×1080 for 4:3)
Text overflow detection is inaccurate	measure always scaled the SVG viewBox to 1080
Preview is cropped top and bottom in the Web UI	aspect-[16/9] frame + object-cover crops ~25% vertically

Note that lint is not involved in the main symptom — the model never attempts
y>1080 in the first place, so it is never pushed back by lint. The false
out-of-bounds warning is both an independent symptom and a landmine that only
detonates once the knowledge layer is fixed. That is why the implementation
order is fixed as engine layer → knowledge layer.

Changes

Engine (8243368f)

• Added slide_size_px() / emu_per_px() to sdpm.engine and replaced the
  inline computations in builder and converter (behaviour unchanged)
• analyzer: dropped the fixed emu=6350 in favour of the 1920-width basis
• lint: removed the height out-of-bounds check, making lint independent of
  slide size
  • Rationale is a cost asymmetry: a false positive actively misleads the agent
    into breaking the layout, while a false negative is caught by the
    generate-time check and by preview inspection
  • The width check is a constant that is always correct, so it stays
  • As a result, both the lint(data, slide_size=...) API extension and the
    cache-staleness problem on the remote save path (where the template binary is
    unreachable) disappeared from the design entirely
• generate: added a height-bound warning based on the template's real
  dimensions (zero false positives) and a slideSize mismatch warning
• deck.json: the engine writes slideSize only when creating a new deck
  (api.init / pptx import); it never updates an existing deck.json.
  deck.json is the spec the agent writes — if the engine rewrote existing
  values, the single-writer principle would break and generate would gain a
  side effect of mutating its own input
• measure: switched to an isotropic scale derived from the viewBox width
• Unified the basis for grid overlay, imbalance reporting, and detect_layout

Knowledge layer (30b33f0c)

• Canvas dimensions rewritten as "width is always 1920, height comes from
  slideSize"
• Derived values (drawing area, etc.) now teach the derivation and keep the
  16:9 numbers as an example
  • Ratio scaling would be the wrong abstraction: y=173 is
    title.y2 + margin (a placeholder-derived absolute) and y=950 is
    "130 px above the bottom" (an absolute margin). Fattening the title band by
    1.33× on 4:3 would be incorrect
• art-direction / vibe now record slideSize into deck.json
  (vibe never calls analyze_template, so deck.json is the only path that
  reaches the composer)
• composer gained the rule "width is fixed at 1920, height varies — always read
  slideSize"

Web UI and live preview (d4d6faa3)

All three problems came from one variable carrying two different meanings.

1. Preview follows the real aspect ratio (symptom 5 in the issue)

   • Slide previews (SlideThumbnail / WorkspaceView / SlideCarousel /
     AnimatedSlidePreview) now follow the actual ratio
   • The width cap keeps the existing "convert a height constraint into a width
     limit" structure and only the ratio is lifted from the child. Using w-fit
     instead collapses the width to 0 (parent width ← child width ← parent width)
   • Deck list cards are intentionally left unchanged — CSS Grid rows align
     to the tallest cell, so mixing 16:9 and 4:3 decks would leave ~33% blank
     under the 16:9 cards. These are identification thumbnails, so cropping is
     acceptable
   • No metadata propagation (API / types / DDB) was needed

2. The first few slides never animated (pre-existing)

   • Animation was suppressed for 3 seconds after the slides tab appeared, and a
     new deck switches to that tab as soon as slides arrive — so the first
     slides were always shown instantly
   • Replaced the time-based approximation with a mount-time fact. This is the
     design that was already reached on 2026-04-13; the 3-second timer was a
     later addition whose rationale was never documented

3. The PNG fallback never appeared (pre-existing)

   • setError(false) ran on every 1-second poll, so the fallback was unmounted
     before it could be seen
   • When the render container was not mounted the URL was marked as processed,
     leaving a permanently black box
   • A payload with neither bgSvg nor components is now treated as a failure
     (a background-only slide is still legitimate)
   • SlideThumbnail gained onError and an explicit placeholder when
     previewUrl is missing

Documentation (392f833d)

• A "Slide size (aspect ratio)" section plus known limitations in
  docs/en/custom-template.md
• CHANGELOG.md [Unreleased]

Testing

• make all — 804 passed, 6 skipped
• cd web-ui && npx eslint src/ --quiet && npx tsc --noEmit && npm test —
  229 passed
• Six new test files. analyzer had no tests at all, so tests pinning its 16:9
  behaviour were added before changing it — without them, "existing tests pass
  unchanged" would not have been valid evidence of 16:9 invariance
• tests/test_converter_scale.py and test_converter_elements.py pass
  unchanged, which is the evidence for 16:9 invariance

Verified on a live AWS deployment

• A 4:3 template uses the full canvas (1920×1440 px)
• Existing decks render their previews
• New decks show the live preview and animate

Security scan

ash scan --mode local --fail-on-findings reports 20 findings and fails, but
all of them come from npm-audit (hono / ip-address / postcss / next /
sharp / undici) and are unrelated to this PR. There are no findings from the
code itself — bandit, semgrep, detect-secrets, and checkov all pass. Dependency
updates are handled by Dependabot and are out of scope here.

Out of scope (known limitations)

Item	Reason
Architecture-diagram box auto-height under-estimates by ~25% on non-16:9 (layout/placement.py)	The calibration needs the physical EMU width plumbed in, which would break the arch layout engine's "template-agnostic pure px space" property. That is a different kind of change from the rest of this PR (which only uses dimensions already at hand), so it will be a separate issue. Workaround — specify box.height explicitly — is documented
The 8 style-gallery HTML files are fixed at 1920×1080	The composer only consumes :root design tokens, so documenting "style demos use a fixed 16:9 canvas" is sufficient
Deck list thumbnails are cropped	Accepted deliberately as a trade-off for consistent grid row heights
Web UI skeleton ratio (layout shift before the image loads)	Making this exact requires metadata propagation; deferred
Several slides animate at once when switching from the spec tab to the slides tab	Solvable with visibility-based detection (IntersectionObserver); a separate improvement from this PR

Note

No 4:3-specific branching was introduced, so other ratios such as 16:10 and A4
work automatically. Verification was concentrated on 4:3.