Extension leaves chrome.proxy.settings active after being disabled, causing ERR_PROXY_CONNECTION_FAILED on all browsing

Summary
When the extension is loaded unpacked and then Developer Mode is toggled off in the browser (or the extension is
otherwise disabled without being formally removed), the proxy policy it set via chrome.proxy.settings remains active
while the extension itself becomes invisible in chrome://extensions. Since the local proxy (127.0.0.1:57418) is no
longer being served by anything, the entire browser becomes unable to load any page with:

ERR_PROXY_CONNECTION_FAILED
There is something wrong with the proxy server, or the address is incorrect.

The user has no obvious recovery path from the UI — the extension isn't shown, so it can't be removed; and the system
proxy settings look fine because the override lives inside the browser's extension policy, not Windows.

Environment

• Browser: Brave 147.1.89.141 (Chromium-based) on Windows 11
• Loaded the extension unpacked via Developer Mode
• After some time, Developer Mode was toggled off; the extension disappeared from chrome://extensions but its proxy
  policy stayed in effect

What I found in the profile

Inside User Data/Default/Secure Preferences:

"extensions.settings.": {
"location": 4,
"path": "…/ts-browser-ext",
"preferences": {
"proxy": {
"mode": "fixed_servers",
"server": "127.0.0.1:57418",
"bypass_list": "localhost,127.*"
}
}
}

Recovery required manually editing Secure Preferences (plus the corresponding protection.macs entries) to drop the
extension record.

Suggested fixes

1. Clear the proxy policy when the extension is unloaded / suspended, e.g. in a chrome.runtime.onSuspend handler,
   chrome.management.onDisabled, or via chrome.proxy.settings.clear({ scope: 'regular' }) on teardown.
2. Consider setting scope: 'regular_only' / session-scoped rather than fully persistent so a restart doesn't silently
   reapply the override.
3. Detect unreachable 127.0.0.1:57418 at runtime and fall back to direct mode instead of hard-failing every request.
4. Add a troubleshooting note to the README for users who get stuck in this state (manual steps to edit Secure
   Preferences, or the brave://net-internals/#proxy → re-apply flow, which by itself doesn't fix it since the policy is
   extension-owned).

Start by tracing where chrome.proxy.settings is configured and review the lifecycle entry points named in the issue: chrome.runtime.onSuspend, chrome.management.onDisabled, and chrome.proxy.settings.clear({ scope: 'regular' }). Compare teardown behavior with the persistent policy described in Secure Preferences; done means disabling or unloading the extension no longer leaves 127.0.0.1:57418 active, with the README troubleshooting note added if that remains in scope.