test: pin launchpad#80 + nb_nebi_kernels#5 for integration build [DO NOT MERGE]

[viniciusdc]

Summary

DO NOT MERGE. Integration-test scaffolding so CI builds a singleuser image
that carries the remote-Nebi-kernel work end to end — the backend that emits
state metadata and the frontend that renders it.

Pins the singleuser image's two Nebi-related deps in
images/jupyterlab/pixi.toml to MUFFANUJ's open PR branches:

dep	from	to
nb_nebi_kernels	==0.1	git+https://github.com/MUFFANUJ/nb-nebi-kernels.git@surfaceRemoteEvns
jupyterlab-launchpad	==1.0.5	git+https://github.com/MUFFANUJ/jupyterlab-launchpad.git@nebi-kernel-metadata-refresh

The two are pinned together on purpose: jupyterlab-launchpad's new state
badges / sort ranking / refresh-kernels command only render meaningful data
when the kernelspec manager emits the nebi_* metadata, which is exactly what
the nb-nebi-kernels branch adds. Pinning only the frontend would load the
code against an empty metadata contract.

What's in the diff

• images/jupyterlab/pixi.toml
  • the two git pins above (locked to 28cc06b launchpad / ebbb50f kernels)
  • nodejs = ">=20" made explicit. jupyterlab-launchpad is a TS/JS
    extension whose git source builds via a jlpm build:prod
    hatch-jupyter-builder hook (the branch gitignores the prebuilt
    labextension/), so node must be on PATH during pixi install. It was
    already present transitively via jupyterlab; pinning it explicitly keeps
    the source build from silently breaking if that transitive edge moves.
• images/jupyterlab/pixi.lock — regenerated so pixi install --locked
  (used by images/Dockerfile) resolves both git sources. No new transitive
  Python deps; no incidental jupyter-vscode-proxy HEAD drift this time.

Test plan

• Build Docker Images produces quay.io/nebari/nebari-data-science-pack-jupyterlab:pr-<n> (amd64 + arm64). Watch the launchpad jlpm build:prod step — first git-sourced JS extension in this image, so the node build path is exercised for the first time.
• Test Deployment (k3d) passes — singleuser env installs without breaking.
• Manual smoke on the Hetzner Nebari deploy: with NEBI_REMOTE_URL + JWT in the pod, remote-only workspaces surface as remote-not-pulled kernels and local kernels classify (ready / local-not-installed / local-missing-deps) in the launcher.

References

This image build is the integration vehicle for:

• Tracking issue: Surface remote Nebi envs as kernels with state, version drift, missing-dep detection, and refresh trigger nb-nebi-kernels#2 (surface remote envs, state, drift, missing-dep, refresh)
• Backend PR: surface remote Nebi kernels nb-nebi-kernels#5 (surface remote Nebi kernels)
• Frontend PR: consume nb-nebi-kernels state metadata and add explicit refresh trigger jupyterlab-launchpad#80 (consume nb-nebi-kernels state metadata + refresh trigger)
• Supersedes the kernels-only test pin in test: pin nb_nebi_kernels at PR #5 for integration testing #59 (closed)

Once both upstream PRs land and a nb-nebi-kernels release is cut, the
production pins bump to the tagged versions and this branch is dropped.