CI: mobile e2e smoke + drop SKIP_MOBILE from Makefile

[moodyjmz]

Closes #261.

• Bumps web-apps to pick up docs: Add SECURITY.md #158 (removes SKIP_MOBILE), then drops the now-dead pass-through from develop/setup/Makefile.
• Adds e2e/tests/mobile-editor.spec.ts: a runtime smoke test for docx/xlsx/pptx/pdf mobile editors, catching the class verify-deploy.mjs can't — artifacts deploy but the editor breaks at runtime (Regression: mobile editor doesn't load in latest-dev #258).

Scope

The gate verifies the mobile build is present and renders a document. It keys on the loading skeleton (.doc-placeholder) clearing — the real "document loaded" signal — rather than the canvas, which mounts with the SDK bundle before any document loads and so can't distinguish "loaded" from "never loaded".

Infra faults (e.g. an unresponsive docservice channel) are out of scope: CI runs a healthy docservice from the same image and won't produce them. A known false-pass in that mode is deferred — closing it properly needs a content-bearing sample file rather than a blank new document.

Test plan

• Existing desktop suite (example-page.spec.ts) unaffected
• New mobile suite passes on a working build (4/4)
• Reds on a missing mobile bundle (.doc-placeholder never clears)

[MonaAghili]

PR #262 Review Issues

Issue 1 — Canvas toBeVisible is not a loading-completion signal

mobile-editor.spec.ts lines 54–55:

await expect(frame.locator(editor.canvasSelector)).toBeVisible({ timeout: 30_000 });
await expect(frame.locator(ERROR_SURFACE_SELECTOR)).toHaveCount(0, { timeout: 30_000 });

The test's own comment admits #id_viewer / #ws-canvas are "part of the static UI scaffold" that stay visible even when the document fails to load. So the toBeVisible check only confirms the React app shell mounted — it says nothing about whether the document loaded. The real gate is the toHaveCount(0) line below it.

This matters when the test fails: Playwright reports "canvas not visible" when the actual problem is likely an error dialog or a stuck preloader. Compare to the desktop test (example-page.spec.ts) which checks #loading-mask toBeHidden — a direct "document finished loading" signal. If a mobile equivalent selector exists, it would give clearer diagnostics and closer parity with the desktop suite.

---

Issue 2 — Two sequential 30 s timeouts against a 60 s global

Note: You did not introduce the 60 s global timeout — that is pre-existing in playwright.config.ts and unchanged by this branch. This issue is flagged because his new test introduces the two back-to-back timeout: 30_000 assertions that, combined with the existing ceiling, leave no margin. The problem only exists because of what he added; fixing it is his to do.

playwright.config.ts sets timeout: 60_000 per test (pre-existing). The new mobile tests chain two assertions that each allow up to 30 s:

// step 1 — up to 30 s
await expect(frame.locator(editor.canvasSelector)).toBeVisible({ timeout: 30_000 });
// step 2 — up to 30 s
await expect(frame.locator(ERROR_SURFACE_SELECTOR)).toHaveCount(0, { timeout: 30_000 });

Worst-case: step 1 takes 29 s (slow container, slow JS parse), step 2 takes 29 s (slow document load) → 58 s total before the test even returns. Playwright's global timer is already at the ceiling. In practice the canvas check resolves quickly, but on a degraded self-hosted runner there is no margin. Either reduce the canvas timeout (e.g. 15_000, matching the global expect.timeout in config) or raise the per-test timeout for this describe block via test.setTimeout.

[Aiiaiiio]

Nice one! This verbose commenting will make this a bit hard to maintain should anything change that is stated here. But at least it's obvious what is happening.