Clarify the document associated with ModelContext #379

Every ModelContext method finds the Document it operates on as this's relevant global object's associated Document. For a Document that doesn't have its own browsing context, that's a different Document from the one whose modelContext was accessed.

Example

document.implementation.createHTMLDocument() creates a Document in the creator's realm, and the spec says its ModelContext is "created in the Document's relevant realm". So:

const doc = document.implementation.createHTMLDocument();
doc.modelContext !== document.modelContext;        // true: separate objects
// But for doc.modelContext:
//   relevant global object  === window
//   its associated Document === document   (not doc)

The same applies to Documents from DOMParser, XMLHttpRequest.responseXML, document.implementation.createDocument(), new Document(), and <template> content documents.

What the spec says happens

For doc.modelContext:

• registerTool() (L789-L793) runs the fully active and Permissions Policy checks against document, so they pass. It then adds the tool to doc.modelContext's own tool map and notifies other documents as if document had registered a tool. Nothing ever finds that tool, because getTools() and perform an observation only read the tool map of each navigable's active document.
• getTools() (L929-L933) and executeTool() (L1059-L1062) succeed, and behave as if document had made the call.
• Unregister a tool (L656) notifies on behalf of document.
• Signal tool stability with waitForToolsUntil() and ToolChangeEvent #373 adds the same pattern to waitForToolsUntil() and the toolsReady getter. As written, doc.modelContext.waitForToolsUntil(p) would change document's tools-ready state.

Proposal

1. Give each ModelContext an associated Document, set in the existing "Upon creation of the Document object…" step to the Document being created.
2. In every ModelContext algorithm (registerTool(), getTools(), executeTool(), waitForToolsUntil(), toolsReady, unregister a tool), replace "this's relevant global object's associated Document" with "this's associated Document". Keep using the relevant global object wherever a global is actually needed (for creating promises and for queuing tasks).
3. The existing fully active checks will then reject for Documents without a browsing context, which matches Chromium and WPTs.

WPTs

Existing WPTs check for this and contradict the spec:

• webmcp/imperative/model_context.https.html: "createHTMLDocument().modelContext rejects tool operations with InvalidStateError" (registerTool, getTools, executeTool)
• webmcp/imperative/wait-for-tools-until.https.html: "waitForToolsUntil() throws InvalidStateError in a document without a frame"