docs: explain the honeypot styles filter for strict CSP setups

[2ndkauboy]

Adds a FAQ entry explaining the antispam_bee_honeypot_styles filter for sites with a strict Content Security Policy — the situation the filter was introduced for (support topic, referenced in the filter's own docblock in src/Helpers/Honeypot.php).

Documentation only, no code change. The counterpart for the 2.x line is in #847.

What it says

A style-src directive without 'unsafe-inline' makes the browser drop the honeypot's inline styles, so the field becomes visible to visitors. The entry then gives the way out:

• add_filter( 'antispam_bee_honeypot_styles', '__return_empty_string' ); so no inline styles are rendered
• the equivalent CSS to move into a stylesheet the policy already allows
• a warning against hiding the field with display: none or visibility: hidden, which many spam bots skip — that would quietly defeat the honeypot

Notes on the details

The selector is [aria-label="hp-comment"], without an element name on purpose: Helpers\Honeypot::get_honeypot_field() copies the id and the name from the real comment field, and builds either a textarea or an input depending on what the form uses, so the aria-label is the only stable hook. The entry says so explicitly, since a reader would otherwise reach for #comment.

Placed after the AJAX question, next to the other developer-facing integration topics, and formatted with the same single-backtick code blocks as the neighbouring antispam_bee_patterns entry.

[github-actions]

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

---

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check