notebooks: port Docker launcher to TypeScript notebook series

[FrancescoRosciano]

Context

PR #79 added an optional Docker launcher to examples/notebooks/python/:

• Dockerfile + docker-compose.yml (Python 3.13-slim + JupyterLab + getpatter)
• _setup.in_docker() and _setup.start_docker() helpers
• Optional commented launcher cell at the top of all 12 Python notebooks

Per .claude/rules/sdk-parity.md, the TypeScript notebook series at examples/notebooks/typescript/ should mirror this surface. The Python module docstring currently acknowledges the gap.

Scope

Land all four in a single PR:

• examples/notebooks/typescript/Dockerfile — Node 20-slim + Deno (or tslab) Jupyter kernel + JupyterLab. Decision needed: Deno Jupyter vs tslab. Deno is what the existing TS notebook quickstart uses, so prefer Deno unless there's a deal-breaker.
• examples/notebooks/typescript/docker-compose.yml — same shape as the Python compose file (loopback-only ports, optional .env, JUPYTER_TOKEN passthrough, PUID/PGID build args).
• examples/notebooks/typescript/_setup.ts — inDocker(): boolean and startDocker(opts): Promise<boolean> mirroring the Python signatures (camelCase per parity rule). Same env-var contract: PATTER_NOTEBOOKS_IN_DOCKER, PATTER_NOTEBOOKS_NO_TOKEN.
• Optional commented launcher cells at the top of all 12 TypeScript notebooks.
• Update examples/notebooks/python/_setup.py module docstring to drop the parity caveat once shipped.

Acceptance

• cd examples/notebooks/typescript && docker compose up --build opens JupyterLab at http://127.0.0.1:8888 with a generated token.
• _setup.inDocker() returns true inside the container, false on host.
• _setup.startDocker() returns false on every error path (no docker CLI, missing compose, non-zero exit) with stderr captured.
• Vitest unit tests parallel tests/test_docker_bootstrap.py (19 cases on the Python side).

Notes

• Estimate: M (~1 day, mostly the kernel choice and writing parallel tests).
• Use the Python implementation as the reference — it incorporates security-review fixes (loopback bind, token by default, non-root, pinned deps, captured stderr).

[EXDEV-oss]

Hey — just following up on this.

If it’s not something you need right now, no worries.

I only ask because small integration issues usually don’t show up until real usage starts — and they’re usually quick to fix once spotted.

Happy to take a quick look if you still want feedback.