Intermittent issue - new WebView2 control instance inherits session cookies

[ShaunLoganOracle]

Description
Our Excel add-in creates and disposes multiple WebView2 instances in WinForms. The WV2 instances all share the same User Data Folder (for a given Excel process). At one point the add-in uses a WebView2 instance to log into a web application and captures the cookies issued during the login sequence. On subsequent creation and use of a new WebView2 instance to access pages in the web app, we use CoreWebView2.CookieManager.AddOrUpdateCookie() to apply the cookies previously captured to the new instance. This all works as expected, even after the user logs out via the add-in UI (this clears the set of cookies). After Logout, on a subsequent creation of a new WebView2 instance, we don't AddOrUpdateCookie because we don't have any, and so the user is redirected to the login page. However, intermittently, the new WV2 instance still appears to send cookie headers to the web app, as if these session cookies were somehow persisted or inherited from a previous instance, in that case, there is no redirection to the login page and the protected resource is rendered.

Are there any known issues in WV2 that would be consistent with these observations?

Version
SDK: 1.0.1774.30
Runtime: 115.0.1901.203 (or thereabouts)
Framework: WinForms
OS: Windows 10 (22H2)
Note: we are running as an Excel VSTO add-in

Repro Steps
Capture cookies from "login" WV2
Use them on subsequent instances of WV2
Logout (clear add-in's cookie set)
Rinse and repeat this sequence many times, and then at some point
A fresh instance of WV2 is created (after Logout), so no cookies are applied, but the WV2 control is still successful navigating to a protected page in the web app.

Additional context
We have not been able to reliably reproduce this which has prevented us from capturing a Fiddler trace.
The add-in captures all cookies, which could be a combination of session and persistent cookies. We would expect the persistent cookies to be sent in all cases, but at least one session cookie is critical for the authentication of the web app. Since the add-in does not set that session cookie/cookies into the new WV2 instance, we would not expect the navigation to the protected resource to succeed, but somehow it does, and we can only conclude that the new WV2 instance is sending that session cookie somehow.