Add Danbooru rule for post listing pages

[yydfh33]

Disclosure: This rule was developed with Claude (Anthropic's AI
assistant). The AI could not access Danbooru directly, so every finding
below came from diagnostic scripts I ran in my own browser and pasted back;
the mechanism analysis is the AI's interpretation of that output. Everything
described under "Tested" was verified by me on a live page.

This adds a narrower rule for Danbooru's post listing pages. It does not
replace the existing Danbooru rule by @skofkyo — that one also covers
e621.net and Danbooru's other pages (comments, tags, pools), which this rule
deliberately leaves alone.

Problem

The existing rule uses "pageElement": "article", which is not scoped to the
post grid. In practice auto-detection falls back to iframe mode, loading the
entire next page — sidebar included — into a narrow iframe appended at the
bottom. Danbooru's grid is responsive, so the reduced width renders thumbnails
noticeably smaller, and click-to-enlarge does not work across the iframe
boundary. Disabling iframe mode alone produces duplicate posts.

Two Danbooru-specific quirks

1. Posts start hidden. Blacklist#initialize() builds this.posts as a
one-time snapshot of the posts present at load, so elements inserted later are
never evaluated and keep visibility: hidden — they occupy layout space but
stay invisible. Danbooru.Post.initialize_all() does not re-scan them.

The rule recovers the live Blacklist instance via
someInitializedPost.post.blacklist, registers each inserted post with
new Danbooru.Blacklist.Post(el, bl), then calls bl.apply(). This runs the
site's own rules, so user blacklists stay in effect on inserted pages.

2. Thumbnail variant. Previews are served as
<picture><source type="image/webp" src="...720x720....webp"> — note src,
not srcset. Danbooru's own script rewrites that attribute after load;
inserted posts miss it and fall back to the <img> 360x360 JPEG. The rule
reads which attribute an already-initialized <source> ended up using and
mirrors that on inserted posts, rather than hardcoding either behaviour.

Timing matters for both. The Blacklist instance is reachable through an
Alpine-reactive property that is not ready at insertion time, so pageAction
retries every 150 ms (up to 20 times) until it resolves. Running immediately
silently does nothing — no error, no effect.

Tested

Chrome + Tampermonkey, logged in, 2026-09. Listing pages: no iframe, no
duplicates, all inserted posts visible, blacklist applied, thumbnails at the
same variant as page 1, no broken images. Post detail pages (/posts/<id>)
unaffected — still handled by the existing rule. Not tested while logged out.

Question

When two rules match the same URL, which takes precedence? I placed this entry
before the existing one assuming first match wins.

I verified the behaviour I care about — listing pages use the new rule and
detail pages still work — but I did not test the ordering itself (e.g. whether
moving the entry after the existing one changes anything), so the placement is
an assumption rather than a verified requirement.