feat(app): show the app version in the window, the tray menu and About

[HackPoint]

What

The app version was only in a startup log line. It now shows in three places, all read from the build at runtime (no version string of Lumen's own in the frontend or in Rust):

Where	What	Source
Main window header	Lumen <version> under the tagline	getVersion() (plugin:app|version)
About section, bottom of the main window	Version -> <version>	same
Tray menu	first item, Lumen <version>, disabled	app.package_info()

Both resolve to Tauri's PackageInfo, which Tauri fills from tauri.conf.json when the app is compiled.

Lumen has no settings window. The Setup screen is first-run only and runs lumen_run_setup as soon as it opens, which an e2e must not trigger (on Windows it runs in the runner's real profile). So About is a labelled section of the main window (aria-labelledby -> "About" heading, dl: term "Version", value). Sidecar versions are not shown (not cheap); the consistency test below covers them instead.

Tray item cannot be clicked

It is built with enabled = false, which is greyed and not activatable on macOS, Windows and Linux. It also has its own id (version), which the menu-event handler in lib.rs does not act on, so a click that did arrive would still do nothing. The menu is built from a plain-data spec (tray_menu_entries) because muda creates items on the main thread only, so the real menu cannot be built in a test. The spec is what the tests check; build_tray_menu_items turns it into items one-to-one. The real macOS/Windows/Linux menu is not rendered by any test.

Tests

• Rust (health.rs): the_version_the_ui_shows_is_the_one_tauri_conf_and_every_cargo_toml_declare takes the PackageInfo the build embedded and asserts it equals tauri.conf.json, the Tauri crate's Cargo.toml and every crates/*/Cargo.toml (the sidecars). Red proofs run locally: tauri.conf.json bumped alone -> fails listing the six Cargo.tomls; crates/lumen-mcp/Cargo.toml bumped alone -> fails naming it; both restored -> green. Two more tests: the tray line is first, disabled, and built from the version it is given (red with enabled: true; red with a hard-coded label); Open/Quit stay enabled.
• Frontend (home.spec.ts): renders Home with a seeded version no release has (9.8.7, 0.0.1-rc.2) and asserts header text, About text, the aria structure, absence before it loads, and unavailable on failure. Red with a literal in the template. ng test thresholds all met.
• App e2e (app.e2e.mjs): new test reads the expected version from tauri.conf.json and Cargo.toml at run time (asserting they agree), then waits with s.until for .home__version and .about__version and asserts Lumen <v> / <v> plus the About structure. No sleeps, no retries. Harness startup/wait code is untouched.
• macOS: no tauri-driver there. issue5-launch-check.sh reads the expected version from tauri.conf.json (plutil) and Cargo.toml, and asserts the exact lines Lumen <v> and <v> in the accessibility text (a previous run's artifact shows the full page, below the fold, one line per text node). Under the OCR fallback a miss is a LIMITATION, not a failure.

Who asserts what

	header + About text	tray item
Ubuntu	App e2e (ubuntu-22.04)	Rust unit test (spec)
Windows	App e2e (windows-latest)	Rust unit test (spec)
macOS	Issue 5 launch check (macOS), plus the frontend unit tests in Check	Rust unit test (spec), Test (macos-14)

The added e2e test is one more app launch, so it has one more exposure to the known Windows startup flake (owned by T5).

Local gate

/tmp/lumen-verify.sh -> GATE GREEN (fmt, clippy, tests, frontend build + coverage, sidecars, cargo test -p Lumen, msrv, verify-install, debug app build).

Also

tauri::generate_context!() may be expanded once per binary and the unit-test binary contains run(), so it now lives in one app_context() that run() and the test share. CHANGELOG entry added.