fix(deps): stop JupyterLab 4.6 flagging the launcher dependency

[pjdoland]

Summary

jupyter labextension list on JupyterLab 4.6 marks @plmbr/notebook-intelligence as incompatible:

"@plmbr/notebook-intelligence@5.4.0" is not compatible with the current JupyterLab
Conflicting Dependencies:
JupyterLab           Extension      Package
>=4.6.3 <4.7.0       >=4.2.0 <4.3.0 @jupyterlab/launcher

The extension still loads and the launcher tiles work, because a prebuilt extension's compatibility flag only affects what the listing prints. The X still suggests a broken install to anyone who runs the command. The cause is the ~4.2.0 range on @jupyterlab/launcher, which JupyterLab compares against its own ~4.6.x pin.

Solution

• Declared range. @jupyterlab/launcher goes from ~4.2.0 to ^4.0.0, matching the other @jupyterlab/* dependencies, the README's "JupyterLab 4.x", and CI's jupyterlab>=4.0.0,<5. NBI only uses the ILauncher token and launcher.add() with command, category, and rank, all of which exist in 4.0.
• Locked version stays 4.2.7. 1269f67 pinned ~4.2.0 because resolving launcher to 4.5.x mixed @lumino/coreutils versions and broke the Token<ILauncher> type in the build. Running jlpm install against the wider range re-resolves launcher to 4.6.x and pulls about 290 lines of 4.6-era packages into the lockfile. Instead, yarn.lock keeps the existing 4.2.7 entry (same resolution and checksum) under the ^4.0.0 descriptor, and the workspace entry matches package.json. The TypeScript build therefore sees exactly the types it saw before.
• Runtime unchanged. Launcher is a shared singleton that is not bundled. The built extension already loads the host's copy, with its required version taken from the core metadata at build time rather than from this range.

JupyterLab's own overlap check (jupyterlab.commands._test_overlap) against host launcher pins:

Host	~4.2.0 (before)	^4.0.0 (this PR)
~4.0.x, ~4.1.x	incompatible	compatible
~4.2.x	compatible	compatible
~4.5.x, ~4.6.x, ~4.7.0-alpha	incompatible	compatible
~5.0.x	incompatible	incompatible

Testing

• Lockfile. jlpm install --immutable --mode=skip-build accepts it with no further changes, and node_modules/@jupyterlab/launcher is still 4.2.7.
• Build. jlpm build writes ^4.0.0 into notebook_intelligence/labextension/package.json.
• Compatibility listing. jupyter labextension list in a JupyterLab 4.6.0 environment now reports enabled OK; the same environment reported enabled X before the change.
• Live check. JupyterLab 4.6 with an isolated home directory, with the Claude Code and Codex CLIs on PATH. The NBI plugin activates, and the launcher's Coding Agent section shows the Claude Code and Codex tiles, with no console errors.
• Suites. jlpm tsc --noEmit, stylelint, eslint, prettier, jlpm jest (423 passed), and pytest tests/ --ignore=tests/test_claude_client.py (1753 passed).
• No new tests. A dependency range has no unit to test; the type check, the immutable install, and the compatibility listing cover it.

Risks / follow-ups

• The 4.2.7 hold lives only in yarn.lock. A plain, immutable, or dedupe install keeps it. Regenerating the lockfile or running jlpm up @jupyterlab/launcher resolves the newest 4.x instead and brings back the type error from 1269f67. That failure is loud, since tsc fails in CI. If you would rather make the hold explicit, a bare "@jupyterlab/launcher": "~4.2.0" entry in resolutions survives regeneration. It would be the only resolution that holds a version back rather than setting a security floor, so I kept the smaller change. Happy to switch.
• Build-time core metadata. The runtime requiredVersion for shared core packages comes from the core metadata jupyter_builder resolves at build time (a cached copy of JupyterLab's main when @jupyterlab/core-meta is absent). Pinning that source would make release builds reproducible. This PR does not change it.
• Minimum JupyterLab. The inline completer APIs NBI uses suggest 4.1 is the real floor, so "4.x" in the README and >=4.0.0 in CI may overstate support. This PR does not change it.

No issue was filed for this. It came up while checking the 5.4 release against JupyterLab 4.6, and the details are above.

[pjdoland]

A nudge on this one, with a measurement that I think strengthens the case.

On JupyterLab 4.6, jupyter labextension list --verbose currently reports:

"@plmbr/notebook-intelligence@5.4.1-a1" is not compatible with the current JupyterLab
Conflicting Dependencies:
JupyterLab        Extension        Package
>=4.6.0 <4.7.0    >=4.2.0 <4.3.0   @jupyterlab/launcher

I checked what that warning actually costs, because a compatibility warning is not the same as a broken extension. The extension does load and work on 4.6: the Coding Agent launcher tiles render, which means the ILauncher token resolved. So the warning is advisory. What it costs is that every 4.6 user sees their install described as incompatible, and the extension is listed with a red mark.

The reason this change looks safe is in the lockfile half of the diff. yarn.lock still resolves @jupyterlab/launcher to 4.2.7 after the range is widened, so the build keeps compiling against exactly the version that 1269f67 pinned for when it fixed the Token<ILauncher> private property mismatch. The declared range stops advertising incompatibility with newer JupyterLab, while the resolved version does not move.

All four checks are green here. Happy to rebase if that is useful.