Add "Customize cookie settings" button and preferences panel

[Castellon-ACM]

Summary

Closes #11.

Implements the "Customize cookie settings" button and cookie preferences panel described in the issue, built on top of PR #12 (fix/reopen-trigger-and-link-a11y, not yet merged) since both touch the exact same banner markup/JS (the icon-only reopen trigger and policy-page-title link PR #12 just added). This PR's base branch is fix/reopen-trigger-and-link-a11y, not main — once #12 merges, this should be re-based/re-targeted at main.

Acceptance criteria (from the issue)

• The button appears on the left of the action row with the cookie icon, in bar, box and popup layouts, on desktop and mobile. Printed through the existing frcn_cookie_notice_before_actions action; reuses the same CSS-mask icon technique as .frcn-cookie-notice__icon.
• Clicking it opens the preferences panel; Esc / close button dismiss it and restore focus. Also reachable from the persistent reopen trigger — both triggers open the same #frcn-cookie-preferences dialog and restore focus to whichever one opened it.
• Accept all, Reject all and Save changes produce the same cookie, Consent Mode update and logging as the current buttons — all three (and the banner's own Accept/Reject) call the same handleDecision() in JS and the same log_consent_callback() AJAX endpoint server-side. No parallel consent logic.
• The panel works with a full-page cache: printed unconditionally (including on the policy page), hidden via the hidden attribute, identical HTML for every visitor — open/closed state is entirely client-side.
• Without JavaScript, the banner still works as it does today — the Customize button is hidden via the existing <noscript> fallback (print_noscript_style()); Accept/Reject keep working via the no-JS <form> fallback.
• Hooks/filters exist and are documented in docs/preferences-panel-hooks.md:
  • frcn_cookie_notice_before_actions (existing, reused for the button)
  • frcn_cookie_preferences_categories (new action, fires inside the panel)
  • frcn_cookie_consent_categories (new filter, applied around the per-category payload in log_consent_callback())
  • frcn_cookie_customize_button_label / frcn_cookie_customize_button_enabled (new filters)
• With PRO inactive (nothing hooked to frcn_cookie_preferences_categories), no category UI is rendered — verified in test_no_category_ui_is_rendered_without_an_add_on. With a test add-on hooked in (see test_preferences_categories_action_fires_in_the_right_place and CookieNoticeConsentCategoriesTest), categories show up and are read back through the filter.
• All strings are translatable (text domain frontconsent) and in English; button/panel are keyboard and screen-reader friendly (dialog ARIA, focus trap, live-region announcements reusing the existing announcer).
• Tests added/updated; composer lint and composer phpstan pass; readme.txt/readme.md updated.

What was built

• PHP (includes/Frontend/CookieNotice.php): render_customize_button() (hooked on frcn_cookie_notice_before_actions), render_preferences_panel() (called from render_banner() next to the reopen trigger, unconditionally), the new action/filters above, and get_consent_categories_payload() wiring the categories filter into log_consent_callback()'s JSON response.
• CSS: secondary/outline styling for the button (reusing the existing accent/bg/radius CSS custom properties) and a new dialog styles for #frcn-cookie-preferences.
• JS: hoisted the decision-recording code path (handleDecision, setConsentCookie, updateConsentMode, logDecision, dispatchConsentEvent) out from under the "only if banner exists" gate so it also works on the policy page; added the preferences panel's own focus trap/Escape handling (guarding the banner's own popup trap so only one dialog reacts to Escape/Tab at a time); changed the reopen trigger to open this panel instead of clearing the cookie and reloading.
• Docs: docs/preferences-panel-hooks.md documents every hook/filter, when it fires, and what data is available, plus a minimal PRO-style example add-on.
• Tests: tests/Unit/CookieNoticePreferencesPanelTest.php (button/panel markup, ARIA, the categories action firing, the label/enabled filters, no-JS hiding), tests/Unit/CookieNoticeConsentCategoriesTest.php (the categories filter applied around the AJAX payload), plus updates to CookieNoticeAccessibilityTest.php (scoped an existing assertion now that the panel's own dialog markup is always present) and both tests/js/*.test.js files covering the new panel's open/close/focus-trap/decision-routing behavior.

Test results

• composer test (PHPUnit): 96 tests, 187 assertions, all passing — ran locally against a throwaway MySQL 8.0 instance (Local by Flywheel's bundled binaries, scratch datadir, non-default port), torn down afterward.
• composer lint (phpcs): clean.
• composer phpstan: clean, no errors.
• npm run test:js (node --test): 39 tests, all passing.
• CI will additionally verify PHP 7.4/8.1/8.2/8.3 matrices this session couldn't run locally (only PHP 8.3 was available).

Not done / out of scope

• Per the issue, the actual PRO category-management UI (cookie scanner, category definitions, per-service blocking) is intentionally not built here — only the extension points.
• Issues Add generic script/iframe blocking until consent (Free-tier requirement from docs/plan.md) #5 (script/iframe blocking) and Integrate WP Consent API (unchecked roadmap item) #6 (WP Consent API) are explicitly out of scope for this PR per the current plan.

🤖 Generated with Claude Code