Apps: version pinning with immutable snapshots, detail pages, service runtime, and job lifecycle hardening

[krokicki]

This PR extends the Apps feature with version pinning backed by immutable snapshots, dedicated detail pages for apps, catalog listings, and jobs, a launcher-free runtime for service apps, and a hardened job lifecycle and worker environment.

App version pinning and immutable snapshots

• Apps are pinned to a commit SHA when added (user_apps.commit_sha, plus code_commit_sha for manifests whose code lives in a separate repo_url repo). Jobs run from an immutable per-commit checkout materialized under ~/.fileglancer/apps/<owner>/<repo>/.snapshots/<sha> as a cheap hardlink clone, so a moving branch or a sibling app's update can never change what a job executes. Legacy unpinned rows are pinned on first launch.
• Updating is an explicit per-app action that repoints the pin; already-running jobs and other apps in the same repo keep the tree they were pinned to. A new GET /api/apps/check-updates endpoint compares pins against remote tips (one batched git ls-remote round-trip through the user's worker) and the UI shows update-available badges.
• Snapshots that no app pin or retained job references are garbage-collected, with a grace window for in-flight launches and background deletion so large trees on NFS don't stall the worker.
• Jobs record the commit they executed (commit_sha, code_repo_url) and the job page links it to GitHub.

Adding apps

• New POST /api/apps/discover walks a repo for manifests; the Add App dialog gains a selection step for multi-app repos so users choose which apps to add, and the launch page installs only the app being viewed.
• Manifests are validated at add time: repo_url must be a well-formed GitHub URL and at least one runnable is required.
• A trust notice warns that apps execute arbitrary code as the user, shown both when adding from a URL and from the catalog.

App, catalog, and job pages

• New app detail page (/apps/detail/:owner/:repo) and catalog listing detail page (/apps/catalog/:listingId) replace the old info dialogs, with metadata tables, entry-point lists, GitHub links for manifests and commits, and recent jobs (linked both ways between app and job pages). A shared AppPageHeader unifies the app, launch, and job page headers.
• My Apps and the App Catalog get card/table view toggles with aligned column sets; the catalog gets search and a "hide installed" filter.
• Catalog listings can be edited after sharing (name, description, URL) and unshared from the listing itself; the add-from-catalog dialog shows the sharer, share date, and GitHub source.
• The job detail page is rebuilt around tabs (Overview, Parameters, Script, Output Log, Error Log) with lazy per-tab file loading, browse links and downloads for job files, runtime/queue-wait durations, and exit-code explanations.
• Destructive actions — cancel/delete job, remove app, unshare listing — ask for confirmation first.

Service jobs

• Generated service scripts export FG_HOSTNAME, FG_SERVICE_PORT (a free port picked on the compute node), and a random FG_SERVICE_TOKEN, so a service can bind to a known address and authenticate callers without a custom launcher script.
• With auto_url, Fileglancer publishes the service URL itself once the port accepts connections, with an optional shell-safety-validated service_url_suffix that may splice in the token. Services that manage their own URL keep writing SERVICE_URL_PATH as before.
• Service startup phases are reported to the UI: while a container image is downloading the job page says so instead of a generic spinner.
• The jobs listing fetches all service URLs and phases in one batched worker action instead of one round-trip per job.

Job lifecycle

• UNKNOWN scheduler status is handled as a first-class state: displayed neutrally (not as "Failed"), kept polling as active, and only marked FAILED after a configurable cutoff (apps.unknown_timeout_hours, default 24h) measured from the new status_updated_at column.
• Cancelling a local-executor job now actually stops it: the whole process tree is signalled and termination is confirmed before the job is recorded KILLED; cancel/stop failures are reported on the job page instead of silently swallowed.
• Deleting a job also deletes its work directory, with strict path-shape guards so a corrupt DB row can't turn deletion into arbitrary filesystem removal. Submit-time failures clean up the half-created job row and work dir instead of leaving phantom PENDING jobs.
• Inline job-file reads are capped to a 5 MB tail with an omission marker, so a runaway log can't exhaust server memory or the IPC limit; the full file remains reachable via its browse link. Log views refetch once when a job goes terminal so the last output isn't stale.

Launch form and parameters

• Path parameters gain an exists flag: exists: false marks outputs that need not exist before launch, and output directories are created as the target user at submit time.
• Server-side path validation now checks file-vs-folder type, and the Browse dialog flags a mismatch immediately; it also opens at the parameter's current value.
• Env-tab parameters are a fully separate namespace (values, errors, DOM ids), so a pipeline --profile can coexist with Nextflow's -profile.
• Nextflow pipeline params now use --param=value when needed, so values that start with - (for example --runtime_opts=--nv) stay attached to the intended parameter; this is also enforced at command-build time for older cached manifests.
• Nextflow boolean pipeline params are emitted explicitly as --flag=true or --flag=false, so a user-selected false overrides a pipeline default of true while generic non-Nextflow boolean switches keep their existing omit-false behavior.
• Scheduler extra_args are shlex-tokenized, so quoted LSF resource strings like -R "select[mem>8000]" reach the scheduler as single arguments; quoting survives relaunch and params export. Relaunch restores all three form tabs, including env parameters.
• Non-field validation errors appear in the form's error banner, and parameter labels are associated with their inputs.
• The file selector dialog gets a home-directory default, a toolbar, and an editable path display box.

Worker and security hardening

• The per-user worker environment is built from an allowlist instead of a blocklist, so server secrets can't leak to user processes via the environment; FGC_* is never passed through. Site-specific variables can be granted with the new apps.worker_env_passthrough setting.
• User-supplied manifest paths, commit SHAs, and container cache dirs are strictly validated before reaching disk operations or generated scripts.
• Git-heavy worker actions (clone, snapshot, discovery) get longer IPC timeouts, and update checks fail fast so a slow GitHub can't hang the worker's serial request loop.

Configuration and migrations

• New settings: apps.worker_env_passthrough and apps.unknown_timeout_hours, documented in docs/config.yaml.template.
• Two new Alembic migrations: a7e2f9d31c04 (jobs status_updated_at) and f4a1d8c62e97 (commit pinning columns on apps and jobs). Run pixi run migrate after upgrading.

Tests

• New backend suites for snapshots (test_snapshots.py) and worker actions including process-tree cancellation (test_worker.py), plus substantial additions to the apps, endpoints, catalog, and poll-loop suites (~2,400 test lines added).
• New frontend unit tests for app URL parsing, app icons, and job status handling.

@StephanPreibisch @JaneliaSciComp/fileglancer