Opera native ad blocker vs. declarativeNetRequest: allow-rule precedence and compiled-trie memory retention

Integration boundary

Opera 100+ ships a native ad blocker that compiles filter lists into binary trie structures at startup, while also exposing Chromium's declarativeNetRequest (DNR) API for extensions. The native matcher runs earlier in the network stack than DNR static or dynamic rules.

Goal and constraints

Determine whether an extension's DNR allow rules can reliably override a native block decision, and whether the native blocker's compiled trie structures—which persist across navigations and are only released on browser restart—can be measured or compacted via any public API. The native blocker updates its lists daily through Opera's component updater, while DNR dynamic rules follow a separate cadence, so temporary divergence is expected.

Open questions

1. Is there a documented priority order that guarantees DNR allow rules take effect after a native block match, or does the native matcher's early position make override impossible?
2. Can the heap footprint of the native blocker's retained trie nodes be inspected programmatically (e.g., via chrome.debugger or a DevTools protocol command) without a full browser restart?
3. Does Opera expose any internal flag or policy to trigger recompaction of the native filter engine's memory structures?