e2e: should we add Visio (vsdx) runtime coverage? (currently zero in both suites)

[moodyjmz]

Question

Should the e2e suite gain runtime coverage for the Visio (vsdx) editor, and if so, how?

Context

The mobile smoke test added in #261 (PR #262) deliberately excludes Visio, and the desktop suite never covered it either. So Visio currently has zero runtime e2e coverage in either suite — this is a pre-existing gap, not a regression introduced by that PR.

Verified state on ci/mobile-e2e-smoke:

• e2e/tests/example-page.spec.ts (desktop) covers Document / Spreadsheet / Presentation only.
• e2e/tests/mobile-editor.spec.ts (mobile) covers docx / xlsx / pptx / pdf; Visio is explicitly excluded.
• visioeditor is shipped as a real mobile bundle (it's in deploy-mobile.js's MOBILE_EDITORS), and Visio was one of the four editors that broke in Regression: mobile editor doesn't load in latest-dev #258.
• The only current backstop for Visio is the build-time verify-deploy.mjs artifact-presence check, which confirms the bundle exists but not that it renders a document.

Why it's not trivial

Both suites drive the /example/ create-new flow, which has no blank vsdx template — fileExt=vsdx 500s. So Visio can't be smoke-tested via create-new in either suite until that gap is closed.

Options to weigh

1. Add a blank vsdx create-new template to the example app — unlocks Visio coverage for both desktop and mobile in one go. Most work, best payoff.
2. Point the e2e test at a pre-existing vsdx sample fixture (open-existing) instead of create-new, sidestepping the template gap.
3. Accept the gap and rely on verify-deploy.mjs presence checks as the sole Visio backstop; document the decision and close this.

Ask

Decide whether Visio runtime coverage is worth the tooling investment, and which option to pursue. A Visio-only regression (the #258 class of failure) would currently ship undetected past both e2e suites.