🐛 Banner flickers when cycling between notes that have banners assigned

[jacknoff]

Describe the bug
Banner flickers/re-renders when cycling between notes that have (folder groups) banners assigned. The banner briefly disappears or flashes before settling, as if it's being loaded a second time even when the image should already be cached. It does also seem to affect banners which have been manually set, I believe. Seems to happen here and there, sometimes it's seamless other times it's noticeable.

To Reproduce
Steps to reproduce the behavior:

1. Set up Pixel Banner on any notes (folder group, frontmatter, or any method)
2. Open Obsidian to a note with a banner -- observe a flicker ~2-3 seconds after startup
3. Click through several other notes that have banners assigned
4. After a few cycles, the banner visibly flickers/re-renders when switching notes

Also reproducible on startup: open Obsidian to a note with a folder-group banner, wait ~2-3 seconds, and the banner will flicker once as other plugins finish loading.
Confirmed reproducible in a clean vault with no other plugins or snippets.

Expected behavior
The banner should display instantly and stably when opening a note, with no flicker or re-render after the initial load.

Screenshots (Video + vault)
https://github.com/user-attachments/assets/90ce7711-16d9-482d-8785-75129dce2f62

Test vault: Testvault.zip

Environment:
OS: macOS
Obsidian Version: 1.12.4
Pixel Banner Version: v3.6.18

Additional context
The re-render on startup appears to be triggered by other plugins finishing their loading cycle (~3 seconds in), suggesting the banner is re-initialising in response to DOM changes rather than serving from cache. The intermittent flicker during note cycling suggests the blob URL is being regenerated on each render rather than reused.

Possible workaround for investigation:
The re-render could potentially be avoided by:

1. Caching the blob URL per folder path: if the image for a given folder group has already been loaded and converted to a blob URL, reuse it instead of regenerating it on each note open or DOM change.
2. Debouncing the render trigger: if the banner is re-rendering in response to DOM mutations from other plugins loading, adding a debounce so it only re-renders if the note itself has actually changed (rather than reacting to any DOM activity) would prevent the startup flicker
3. Setting the background-image before the fade-in animation starts: if the image is pre-loaded into the element before the CSS animation begins, the re-render swap would happen off-screen and the fade-in would only trigger once the final image is ready.