Fix(window): refine page-title-action button redundancy and layout positioning

[CookieDarb]

What?

Closes #391

This PR proposes a proposal to refine the visual experience of in-page action buttons (like "Add New", "Add Post", "Add User") in Desktop Mode. It removes these buttons when they duplicate tabs in the window header, and correctly positions them on their own row when they are kept.

Why?

Having an in-page "Add New" button is redundant when the window already has a dedicated tab for the same action in the top header. Additionally, it floats awkwardly next to filter links without breathing room unless an admin notice pushes it onto its own line. This proposal makes the experience cleaner and more consistent.

How?

• includes/render/chromeless-bridge.php:
  • Extracted all active submenu tab URLs in PHP (using the desktop_mode_dock_item filter to ensure custom tabs like "Add Theme" are included).
  • Passed these URLs to the iframe configuration payload.
  • Updated the in-iframe MutationObserver to intercept .page-title-action elements and remove them if their destination matches a tab URL (comparing pathnames and query parameters like post_type, taxonomy, page, and action).
• assets/css/chromeless.css:
  • Removed the page-specific override for themes.php.
  • Applied a universal layout style to .page-title-action to ensure preserved buttons always clear filter links and sit on their own row.
• tests/phpunit/tests/desktopModeRender.php:
  • Added a unit test to verify submenu URL extraction and injection into the script configuration.
• docs/plugin-compat-layer.md:
  • Updated the "Add Theme" tab documentation to reflect the new dynamic URL matching behavior.

Testing Instructions

1. Navigate to Posts (edit.php) in Desktop Mode. Verify that the in-page "Add New" button is removed (since it matches the "Add New" tab).
2. Navigate to Appearance (themes.php). Verify that the "Add Theme" button is removed (since it matches the "Add Theme" tab).
3. Navigate to a screen with no submenus (e.g. a standalone plugin page or custom CPT without menus). Verify that the button remains visible and sits on its own row, cleanly separated from content below.
4. Navigate to WooCommerce Orders. Verify that the "Add order" button remains visible, because there is no equivalent tab in the header.

Screenshots

1. When tab is present

2. When tab is present + admin notice

3. When tab is absent (WooCommerce Orders list)

4. When tab is absent (WooCommerce Coupons list)

Use of AI Tools

AI assistance: Yes
Tool(s): Antigravity
Model(s): Gemini
Used for: Reviewing the existing implementation and suggesting the changes. Final decisions and edits were made by me.

[AllTerrainDeveloper]

This worth some discussions around 🙂

I remember some users were lost because they couldn't find the add buttons, as in the beginning I was also removing them.

Also seems we are removing tooooo much :)

We might need probably more work around some areas

[CookieDarb]

Hi, thanks for the review!

I remember some users were lost because they couldn't find the add buttons, as in the beginning I was also removing them.
Also seems we are removing tooooo much :)

My bad! The mapping logic ended up being a bit too aggressive, and given the context, I think its best not to remove the buttons for now.

However, if needed I can update the PR(or open new) to apply only the positioning changes, such that the "Add New" buttons always stays neatly on its own top row, rather than floating on the same line as the view filters.

Let me know if that is preferred.

[AllTerrainDeveloper]

No worries :)

I think we can dedupe for now, the Add Post would be just a few pixels far away from where the original button was. Let's deal with the change, deduping is always nice.