Feature: op jupyter

### Describe the bug

As a moderately invested openpilot hacker, I want to be able to inspect openpilot logs (e.g. to investigate whether bad driving should be blamed on localization, model, or control) with zero setup.

I do not want to call `apt` or `uv` or `bash` unknown code. I want to be able to work from Ubuntu 26.04. I want to be able to work from Windows XP. I do not know how to exit vim.

Possible UX:

1. `ssh comma`
2. inside a virtual terminal, `op jupyter` starts a jupyterlab server on comma:8888. (The jupyterlab environment contains the full openpilot dev environment, as well as reasonable scientific packages that can be installed on the fly using jupyter magic.)
3. on my desktop, I open https://comma:8888/url-with-token. (maybe this is not secure enough and ssh tunnel would be more appropriate)
4. A default jupyter notebook opens with a cell `SEGMENT_URL=`
5. I fill in the segment URL from comma connect
6. The notebook runs to generate control plots and replay. All using local logs.

Why this is a good idea:

1. No more dependency hell. I don't have a system devoted to work on openpilot full-time, so I don't want to install deps that I don't need.
2. Everyone knows how to use comma connect and jupyterlab.
3. No need to wait to upload logs.

Why this is a bad idea:

1. Juypterlab is a very heavy dependency that contains, among other things, a web server.

- but can it be built only into dev builds and not releaselike builds?

### OS Version

anything with a browser

### openpilot version or commit

_No response_

### Additional info

_No response_

Start from the proposed `op jupyter` entry point and determine how a JupyterLab environment would be provided in openpilot development builds. Define the supported SSH or browser access flow, default notebook behavior, dependency boundaries, and local-log plotting and replay workflow; the feature is done when this end-to-end experience is specified and works securely.

Written by the indexing model from the issue text.