fix: preserve directory locality for notebook cell paths in TS server

[yogeshwaran-c]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

When using TypeScript/JavaScript cells in VS Code notebooks (e.g., with the TypeScript Notebook extension), relative path imports like import { a } from './a.ts' fail with TS(2307) Cannot find module, and "Go to Definition" navigates to a nonsensical path.

This happens because the TypeScript language service client converts vscode-notebook-cell:// URIs into virtual file paths of the form ^/vscode-notebook-cell/authority/path/to/notebook.ipynb#fragment. The TS server sees this virtual path and resolves relative imports against its directory (^/vscode-notebook-cell/authority/path/to/), which does not match the actual directory of the notebook file (/path/to/).

Closes #196172

What is the new behavior?

For vscode-notebook-cell URIs on desktop, the cell identity (authority + fragment) is now encoded into the filename while keeping the path in the same directory as the notebook file. This ensures that path.dirname() returns the actual notebook directory, so the TS server correctly resolves relative imports.

Encoding format

Before (virtual path):

^/vscode-notebook-cell/ts-nul-authority/path/to/notebook.ipynb#W0sZmlsZQ
          directory: ^/vscode-notebook-cell/ts-nul-authority/path/to/  (WRONG)

After (directory-preserving path):

/path/to/~vscode-notebook-cell~notebook.ipynb?ts-nul-authority#W0sZmlsZQ
          directory: /path/to/  (CORRECT - matches actual notebook location)

The reverse conversion in toResource correctly parses these encoded paths back into proper vscode-notebook-cell:// URIs.

Additional context

• This fix only applies on desktop (non-web) environments where fsPath provides a real filesystem path
• The web codepath is unaffected and continues to use the existing virtual path format
• The encoding uses ~vscode-notebook-cell~ as a filename prefix, which is unlikely to collide with real filenames
• Authority is URI-encoded in the filename to handle special characters safely
• The approach was originally suggested by the issue reporter in bb9910b, adapted to the current codebase