A rough sketch:

• Graphs are embedded as <iframe sandbox="allow-script" srcdoc="<some HTML document source>" /> (on demand as they scroll into view). Since the iframe is sandboxed and does not have the allow-same-origin permission, this will more or less cause the browser to treat it as a separate domain with the domain name null, i.e. no access to cookies. (caniuse: explainer kinda-sorta suggests it too) so assuming we ever fix the custom protocols, the iframing wouldn't interfere with those.
• As layered defense, make the iframe's JS logic abort (not load the graph) if the origin is not null, or if the user has auth cookies.
• Set an agressive CSP policy to prevent the iframe from talking to non-Wikimedia domains, so an XSS can't be used to extract user IPs and such. (Iframes don't have headers, so we'd have to modify the ContentSecurityPolicy class to optionally return the policy as meta tags instead. Looking at the code, that seems straightforward.)
• To generate the iframes, we can probably use OutputPage::output( true ) with a fake context (to avoid emitting any headers), when the page is parsed. (At that point we have access to the Vega spec so the data flow is straightforward.) The document could just have an empty body; it would load the ext.graph.render RL module and contain the graph specification as a script that passes it to the renderer. The entire iframe source would then be converted into a JS string and passed to the iframe loader as part of the article page.

Security-wise, this seems solid: iframe sandbox security has the security resources of major browser vendors behind it, the way we rely on its security properties is straightforward, and checking the origin and auth cookies is a still pretty reliable second line of defense. In terms of performance, 1) it would add some bloat to graph specifications (they would be wrapped in an iframe), which doesn't seem like a big deal; 2) it would result in some ResourceLoader requests being repeated once per graph on the page, but they would be read from browser cache (or localStorage cache) so the effect is small, 3) the browser would have to execute the same Javascript several times, in each iframe separately, which still seems minor compared to the amount of JS work graph rendering itself requires.