Save Apps in their own database table

[krokicki]

Move user apps from the manifest table to a dedicated DB table. Always use the cached manifest in the DB, only syncing from disk when they change. The main benefit is that this approach makes the Apps page load much faster.

This PR also contains some minor misc fixes to unrelated stuff like the devcontainer, and code comments.

Summary

• Move user-installed apps from a JSON blob in user_preferences to a dedicated user_apps table, with each row caching the resolved AppManifest so the hot path is a single SELECT instead of disk I/O on every request.
• Add get_or_load_manifest (cache-first read) and refresh_cached_manifest (re-read from disk after clone/pull) so the DB cache stays in lockstep with the on-disk YAML.
• Mount the host ~/.gitconfig into the devcontainer so git operations inside the container use the user's identity.
• Fix misleading comments around job polling — py-cluster-api queries LSF by explicit job IDs, not bjobs -u all.

Details

user_apps table

New Alembic migration c4e8a7d92b15_add_user_apps_table adds:

• user_apps(id, username, url, manifest_path, name, description, branch, manifest JSON, added_at, updated_at)
• Unique constraint on (username, url, manifest_path)
• Index on username

CRUD helpers added to database.py: list_user_apps, get_user_app, upsert_user_app, delete_user_app. The old JSON-blob-in-preferences path is removed from the apps endpoints.

Manifest cache

• get_or_load_manifest reads the cached manifest JSON from the row and validates it. On NULL or schema-validation failure, it falls back to fetch_app_manifest (disk) and writes the fresh value back. If no row exists (preview for not-yet-installed apps), it just reads from disk without inserting.
• refresh_cached_manifest is called after operations that mutate the on-disk YAML (e.g. submit_job with pull_latest=True against the manifest's own repo), keeping the cache consistent.
• GET /api/apps no longer hits disk per app — it returns cached manifests and lazily backfills any rows whose stored manifest is missing/stale.
• POST /api/apps/fetch-manifest, POST /api/apps, POST /api/apps/update, and DELETE /api/apps all go through the new table.

Devcontainer

.devcontainer/devcontainer.json mounts ${localEnv:HOME}/.gitconfig read-only into the container so commits/pulls inside the container use the host git identity.

Polling comments

Updated comments in apps/core.py to accurately describe how the poll loop dispatches a poll action with explicit cluster_job_ids through one user's worker — LSF allows cross-user lookup by ID, so a single worker call covers all users' jobs. No behavior change.

Other

• Lint fix in FgButton.stories.tsx.
• Reverted the earlier minimum-release-age npm config rename.

@StephanPreibisch @allison-truhlar

[allison-truhlar]

I'm finding the added code/overall flow of submit_job to be a little confusing. The YAML manifest is read from cache (fallback to disk) at the very start of this function, but then the repo code itself is confirmed to be cached (and re-pulled if the user selects the pull_latest option, setting it to true) later, at which point it's checked again whether the manifest was updated? It seems that maybe the repo cache should also be checked at the beginning, and the manifest updated if pull_latest=true at that point. I'm also finding the logic of the if/else statement under the #clone/pull repo into the user's cache comment hard to follow - I'm not clear why one branch sets the cd_suffix to one value and also how the value of pulled_manifest_repo is determined.