test: expand assembled-desktop E2E coverage across native boundaries

[Azganoth]

Summary

Expands the Windows-local assembled-desktop E2E suite from its single diagnostics smoke test to seven scenarios, each in its own application session.

• Adds e2e/desktop/run.ts, a Node runner that owns temporary fixtures, isolated-store seeding, scenario sequencing, and cleanup. Each scenario is a separate WDIO invocation against a fresh binary, so no scenario inherits another's application state.
• Adds scenarios for the document lifecycle (open, edit, save, reopen), folder context with real watcher refresh, missing-file error propagation, settings persistence across a process restart, and injected titlebar controls with the clean close handshake.
• Adds shared support modules for semantic menu and tree lookups, structured diagnostics reads, and the run context handed to each spec.
• The runner asserts the embedded WebDriver port is released after every scenario, and WDIO teardown probes the session rather than naming a scenario, so a spec that closes the application is handled without abandoning a live one when it fails earlier.
• A failing run retains fixture-manifest.json with each temporary fixture's expected and actual hash, size, and modification time, captured before cleanup removes the temporary root.
• Drops the tracked .env.example, which documented one optional desktop E2E debug flag now shown inline in CONTRIBUTING.md.

Related Issue

Closes #181

Verification

pnpm test:e2e:desktop passes from a clean baseline: the diagnostics smoke path plus the six added scenarios, each in its own application session. pnpm check:frontend passes.

Manually verified in Windows 11:

1. After a passing run, no Leafdown or driver process remains, port 4445 is released, the temporary fixture root is removed, and the E2E identifier's application data directory is removed.
2. With LEAFDOWN_E2E_FORCE_FAILURE=1, the suite exits nonzero and retains the screenshot, semantic UI snapshot, diagnostics summary, test error, correlated frontend and backend logs, and the fixture manifest, then cleans the same state as a passing run.

Not verified: pnpm check:backend; no Rust sources changed.

Notes

The persistence scenario does not assert a new application run ID, which #181 lists as a step. Checking it required handing the first run's ID to the second spec through a file, and the runner already starts a separate worker and application process per scenario, so a repeated run ID is not a state the harness can produce. The scenario still spans two genuine launches and asserts both the restored setting and the sanitized persisted file.