Prepare App Viewer Pages builds for catalogue and server integration

[saltedlolly]

Purpose

This is one part of a larger, staged change that will eventually let people browse the hosted App Viewer, verify their own Tronbyt Server, and choose a compatible device on that server to install an app.

The later Viewer and server changes depend on the published catalogue being built reproducibly and identifying the app repository it came from. This PR prepares that deployment foundation first; it does not add the installation UI or allow a remote Viewer to install anything.

What this changes

• uses npm ci for reproducible App Viewer builds
• keeps the Pages workflow compatible with both the current Viewer and upcoming optional Viewer assets, including github-logo.svg for per-app source links
• adds a documented manual deployment trigger for publishing changes merged to app-viewer-source
• publishes catalogue-meta.json alongside apps.json
• checks the generated site for missing or unsafe local asset references before deployment
• adds focused tests for the metadata writer and generated-site checker
• adds a path-scoped workflow to run those helper tests when relevant files change

Catalogue provenance

The build publishes catalogue-meta.json containing the app repository and exact commit used to generate the catalogue. This will let the upcoming installation flow confirm that the App Viewer and Tronbyt Server use the same app repository before allowing installation.

The value is generated automatically from the checked-out main revision during each Pages build, so forks identify their own repository and catalogue revision without manual configuration.

Why the workflow spans two branches

The deploy workflow is stored on main, where app catalogue changes occur, while the Viewer implementation is checked out from app-viewer-source. App data and assets therefore come from the exact main revision recorded in catalogue-meta.json, while the static Viewer files come from the dedicated Viewer branch.

After a Viewer-only change merges, the workflow can be run manually to publish it even when no app files changed on main.

Generated-site checking

Before deployment, the new checker verifies required top-level files and follows local script, module, and stylesheet references from the Viewer entry points. It rejects missing files and references that escape the site root, while deliberately ignoring unrelated JavaScript shipped inside individual app asset directories.

Not included

• no App Viewer catalogue or interface redesign
• no Tronbyt Server authentication or installation integration
• no automatic app installation
• no server-side repository refresh behaviour

Those changes remain in separately reviewable follow-up PRs. The installation flow will require an explicit user confirmation on the server and will not trust app source supplied by the browser.

Related staged work

• Harden App Viewer metadata generation #797 hardens App Viewer metadata generation
• Serialize system app refreshes for App Viewer installation flow server#942 coordinates system-app repository refreshes
• a later Viewer catalogue/UI PR will add the updated browsing interface and per-app GitHub source links
• later server and Viewer integration PRs will add repository verification and the confirmed installation handoff

Validation

• node --test .github/scripts/app-viewer-build.test.mjs
• syntax checks for the helper scripts
• workflow YAML parsing
• clean npm ci
• full Pages build with the current hardened Viewer source
• compatibility build with the upcoming Viewer assets, including github-logo.svg, present
• generated-site reference checks across both builds
• simulated fork metadata generation
• artifact scan for local filesystem paths, preview LAN URLs, test credentials, and symlinks

The full builds generated 1,095 app detail pages and 597 author pages with complete local references.