[WC-3505]: Gallery pagination design properties are not applied

[yordan-st]

Pull request type

Bug fix (non-breaking change which fixes an issue)

---

Description

Gallery's Pagination design property (Left / Center) has done nothing since the pagination overhaul. Its CSS keyed off a .widget-gallery-pagination wrapper that the overhaul deleted, so pagination was always right-aligned regardless of the setting.

Restoring it is not a CSS change. Pagination now lives in a three-zone flex bar (*-start / *-middle / *-end) where the zone, not the bar, decides position, and those zones are already used by the selection counter and the load more button. Overriding justify-content inside the end zone would centre pagination at ~83% of the bar width, and doing it with CSS order or grid placement would reorder visually while leaving DOM order fixed — a WCAG 2.4.3 (Focus Order) and 1.3.2 (Meaningful Sequence) defect for a paging control.

So placement is decided in markup by a pure function, resolveZones:

alignment	pagination zone	displaced to end zone	untouched
Left	*-start	selection counter	load more stays in *-middle
Center	*-middle	load more button	counter stays in *-start
Right	*-end	nothing	everything

The rule is total: at most three occupants, three zones, and custom pagination replaces the built-in bar rather than adding to it, so at most one occupant is ever displaced. Displacement was chosen over wrapping to a second row because the counter appears dynamically at selected > 0 — wrapping would shift the page the moment a user selects their first item.

The same result drives the footer, the top bar and the editor preview, so they cannot drift apart. That drift is what produced the second and third fixes below.

Also fixed here

• Custom pagination ignored Position of pagination at runtime — it always rendered below the gallery. Above grid now renders it in the top bar. Both renders it once in the footer, because a widgets placeholder rendered twice would duplicate widget instances, DOM ids and state; check() now surfaces a warning explaining that.
• The editor preview disagreed with runtime on that same setting, showing custom pagination above the gallery while the app rendered it below.

Design property changes (data-widgets)

• Pagination is now a toggle button group with Atlas align icons, matching every other alignment control in Studio Pro, and gains an explicit Right option.
• Property and option names are deliberately unchanged. Studio Pro stores design property selections by property and option name, not by CSS class, so renaming raises CE6083 and CE6087 in every existing app until a developer runs "Update all renamed design properties in project". Verified in Studio Pro during development.
• Dead .widget-gallery-pagination rules removed; fc-middle / tb-middle are now real flex zones so Center is centred by construction rather than incidentally.

Accessibility note, intended: DOM order stays start → middle → end, so alignment now also determines tab and reading order — Left puts the paging controls before the Clear selection button. Visual and focus order stay in agreement, which the CSS-only alternatives could not achieve.

Not in this PR: DataGrid 2's -padding-top container-query typo and its identical custom-pagination position bug ship separately so Gallery and DataGrid 2 changes stay reviewable apart. [WC-3547 Data Grid 2: Stack top bar in narrow containers](#2389 (comment))

Tests: 145 unit tests pass (was 131). resolveZones is covered by an exhaustive 24-combination invariant pass; the bar components are asserted against real rendered DOM per zone.

Planning artifacts: packages/pluggableWidgets/gallery-web/openspec/changes/fix-gallery-pagination-placement/.

What should be covered while testing?

Build both packages into a test project:

• packages/pluggableWidgets/gallery-web
• packages/modules/data-widgets

1. Alignment × position. Gallery with Pagination = Paging buttons. For each of Left / Center / Right, check Position of pagination = Below grid, Above grid, Both. Pagination should sit hard left, truly centred on the bar, or hard right, in both bars.
2. Displacement. Enable multi selection with Show selection count = Bottom. Select an item. With Left, pagination takes the left slot and the count moves right; with Center, the count stays left. Repeat with Show selection count = Top against the top bar.
3. No layout shift. Selecting the first item must not change the footer height or add a row.
4. All three occupants. Pagination = Load more, Show total count on, selection active. Center should give: count left, paging status centred, Load more right.
5. Custom pagination. Enable it and check Above grid (renders in the top bar), Below grid (footer), Both (footer only, plus a warning on the widget in Studio Pro). Confirm alignment moves the custom widgets too.
6. Narrow width. Shrink the gallery container below 500px — the bar should still stack vertically and centre everything, whatever the alignment.
7. Design mode. The page editor should place everything where the running app does, including custom pagination.
8. Keyboard. Tab through both bars for each alignment; focus order must follow visual order.
9. Upgrade safety. An existing page that already had Left or Center selected must show no errors and keep its selection.

[iobuhov]

I don't know - did you tried to read this file by yourself @yordan-st ? 😄
IMO, this file full of unnecessary TS gymnastics. The logic should be more straightforward.
We have 3 placements and 3 elements and it probably not going to change anytime soon.
For example:

if (zones[zone] === null) {
            zones[zone] = occupant;
        } else {
            zones.end = occupant;
        }

Wrapping loop around this if is very unnecessary. We can duplicate the check and do it inside param check.
In more detail:
Instead of if (params.hasCounter) { displaceable.push("counter"); } we can if (params.hasCounter) { zones[zone] = occupant; }

Also, I think word "occupant" is very alian for me here , let's use html slang instead and use word "element".
What also imporatant, instead of leaving big comment explaining dsiplacing, let's declare data sructure similar to natural zones (also rename it to default_slots) where each element has primary slot and fallback slot. (fallback would be end for both ,counter and loadmore).
TLDR:

1. Reduce TS types to minimu, let's keep BarSlots (BarZones) and other required typoes
2. Avoid loops, let's use ifs and direct slot (zone) check

[iobuhov]

One of the biggest changes I need is to replace word "zone" with "slot". Slot is more known term in frontend to denote areas where you can put your elements.
Please rewrite spec, comments, variables and other identifiers. Word "zone" is bit too alien.

[iobuhov]

rename to getElementForSlot

[iobuhov]

rename occupants to elements

[iobuhov]

This structure has problem (as well previous code) - SelectionCounter always get rendered - even if it's not visible. Solution would be extract his to small component that has switch case that returns one element. Also you can wrap Pagination to "FooterPagination" that combines "showCustomPagination" and normal Pagination. Same applies to TopBar. By default new component should return null.
This is "early" optimization, but it just also makes our intent more clear. Also