Test against latest and pre-release versions of Python dependencies on a schedule

Problem

JupyterLab pins its Python dependencies as lower bounds (e.g. tornado>=6.2.0), so every CI run and user install resolves each dependency to its newest release. A breaking dependency release therefore shows up in whatever CI run happens next, looking like a failure of that commit or PR rather than of the dependency.

Example: tornado 6.5.9 broke static file serving through FileFindHandler, and the next push to main failed CI on an unrelated commit.

jupyter_server already covers this with a daily Test Prereleases job; JupyterLab has no equivalent.

Proposed solution

A scheduled daily workflow that installs JupyterLab from source with dependencies resolved to their newest releases, plus a dependency_type: pre variant, and runs a bounded subset of the suite (the python test group alone reproduces the tornado failure). A red run would then mean a dependency release broke JupyterLab, surfacing a break like tornado 6.5.9 within a day with the cause isolated. The pre-release variant adds coverage for upstreams that publish pre-releases, catching those breaks before the final release.