Let virtual documents inherit source-editor visibility for push diagnostics

## Feature request

Provide a supported way for an extension to associate a virtual language document with its open source editor or notebook cell, so the language extension can produce diagnostics without requiring a separate editor tab for the virtual document.

The source is already showing to the user. Only its language-specific projection is hidden. The hosting extension can maintain the projection and map diagnostic locations back to the source; it needs the embedded language extension to validate that projection.

## Concrete use case

Pylance's mapped notebook cell magics use request forwarding for non-Python content. The public feature discussion is https://github.com/microsoft/pylance-release/issues/4969. For example, with `js` mapped to `javascript`, a Python notebook cell can contain:

```text
%%js
const broken = ;
```

The intended experience is a JavaScript syntax diagnostic on the visible cell, without executing it, changing the cell's Python language, or opening an implementation-detail JavaScript editor. This example deliberately uses a syntax error so the basic request does not depend on JavaScript semantic type checking or cross-file project context.

The same need applies to the [documented request-forwarding approach for embedded languages](https://code.visualstudio.com/api/language-extensions/embedded-languages#request-forwarding): register a `TextDocumentContentProvider`, open the virtual document, give it the embedded language, and forward language requests. Receiving already-published diagnostics through `languages.onDidChangeDiagnostics` does not itself cause the language extension to compute them.

## Current integration gap

Opening a `TextDocument` does not create an editor tab, and I could not find a public API for declaring that a virtual document is represented by an open source editor.

In the built-in JavaScript/TypeScript extension, source inspection shows two separate considerations:

1. [`BufferSyncSupport.shouldValidate` and `TabResourceTracker.has`](https://github.com/microsoft/vscode/blob/5c676a962ecf8bde9fae1e0c87e6118c1fbbe1d1/extensions/typescript-language-features/src/tsServer/bufferSyncSupport.ts) normally exclude resources not represented in the tab tracker when project diagnostics are disabled. `TabResourceTracker.has` already associates native notebook-cell URIs with their notebook's tab, but has no equivalent association for an extension-created virtual URI backing that cell.
2. Full semantic diagnostics need more than visibility: [`getSemanticSupportedSchemes`](https://github.com/microsoft/vscode/blob/5c676a962ecf8bde9fae1e0c87e6118c1fbbe1d1/extensions/typescript-language-features/src/configuration/fileSchemes.ts) restricts semantic support, and [`LanguageProvider.diagnosticsReceived`](https://github.com/microsoft/vscode/blob/5c676a962ecf8bde9fae1e0c87e6118c1fbbe1d1/extensions/typescript-language-features/src/languageProvider.ts) filters non-syntax diagnostics when the resource lacks that capability. Merely opening the projection in a tab would not establish complete semantic support for an arbitrary custom scheme.

The public [embedded-language guide](https://code.visualstudio.com/api/language-extensions/embedded-languages#conclusion) also documents diagnostics as a limitation of request forwarding.

## Requested behavior

- Allow an extension to register and dispose a relationship between a virtual document and the source document or notebook cell it represents.
- Let language extensions use that relationship for diagnostic scheduling while the source is open, without displaying the virtual document in another tab or requiring workspace-wide background diagnostics.
- Continue honoring the language's validation settings and normal document-update lifecycle. The host extension remains responsible for updating virtual content and mapping diagnostic ranges back to the source.
- Support syntax diagnostics as a useful minimum. Semantic diagnostics should remain subject to an explicit, supported language-provider integration with sufficient context; this request does not assume that a visibility flag alone can provide correct project-wide type checking.

If an existing supported extension point can express this relationship, documenting that route would also help.

## Related discussion and scope

https://github.com/microsoft/vscode/issues/159911 previously requested a generic pull-diagnostics API and was declined. This request is specifically about representing the visibility/lifecycle relationship and enabling the existing **push** diagnostic model; it is not a request to add another generic execute-diagnostics command. The distinction also addresses the concern about blindly validating unrelated hidden documents: the hosting extension would explicitly identify the source that is open to the user.

https://github.com/microsoft/vscode/issues/59650 concerns broader TypeScript support for virtual file systems; this request is narrower than making an entire virtual workspace semantically equivalent to a filesystem-backed project.

This is a source-grounded feature request, not a newly executed diagnostics reproduction. The notebook navigation failure reported in https://github.com/microsoft/pylance-release/issues/8198 was investigated separately and is not being attributed to diagnostic scheduling.