fix(runtime): guard optional chrome and add 100dvh viewport fallback

[Reebz]

What

Two high-severity fixes found by building and deploying a real 16:9 deck with the skill.

1. Null-guard the Pro runtime. assets/slides-runtime.js runs top to bottom in global scope and dereferences #particles, the nav-dot rail, #progress, and #counter with no guard. A deck that omits any of these decorative elements throws before a single handler attaches, so the whole deck goes non-interactive. The inline template runtime in references/html-template.md already guards these, and this brings the Pro runtime to parity.

2. 100dvh fallback. assets/components.css drives .deck height from 100vh, so the bottom slide line clips under the iOS URL bar and home indicator. Declaring height: 100vh then height: 100dvh keeps the old value where dvh is unsupported and uses the dynamic viewport on modern mobile. The 100vh inside the floatP keyframes is an animation transform and is left untouched.

Test

• testing/fixtures/deck-no-particles.html (added) omits #particles, #progress, and #counter and stays fully navigable by keyboard, dots, wheel, and touch. Before the fix this deck is dead.
• A normally authored deck with all three elements behaves identically, with no regression.
• At mobile widths the progress bar and counter stay visible above the home indicator.

Notes

This is the smallest and highest-value change in a set of eight independent PRs opened against this fork. The other seven build on this runtime and viewport baseline, so merging this one first is the cleanest order.

Co-Authored-By: Leslie Barbara Knope (Claude Opus 4.8 (1M context)) noreply@anthropic.com

[vercel]

@Reebz is attempting to deploy a commit to the bluedusk's projects Team on Vercel.

A member of the Team first needs to authorize it.