[Notebook Migration] Keeping the notebook mapping and Jupyter panel for Python file input

[zyratlo]

Issue #8007 adds Python files as an input to the notebook migration tool. A notebook arrives already segmented into cells, and those cells are what the tool keys its operator mapping off, which in turn drives the Jupyter panel and the click to highlight behavior in the workspace. A script has no cells, so we have to decide what that input gets. There are two options:

A. Workflow only
Send the whole script to the LLM, get a workflow back, stop there. No mapping or Jupyter panel. Smallest change, and no Jupyter dependency for script users at all.

B. Have the LLM segment the script
The mapping call already asks the model which parts of the input became which UDF. For a script we ask for line ranges instead of cell IDs, then build cells from the ranges it returns. Everything downstream is unchanged: same mapping shape, same storage, same panel, same highlighting.

We are leaning toward B.

The reasoning is that the mapping is the only way a user can check the conversion. Migration output is generated, so "which part of my code became this operator" is the first question anyone asks when the workflow looks wrong. Scripts are usually longer and less structured than notebooks, so that question is harder to answer by eye, not easier. Option A would also mean two inputs with visibly different support sitting in the same modal.

B is also cheaper than it sounds, it does not add a round trip, since the mapping call already exists. The new work is reconciling ranges that overlap or leave gaps, plus a script variant of the conversion prompt so existing notebook migrations see byte identical text and are unaffected.

Pushback or any suggestions are welcome, but if there are no objections we will continue with B.