fix(containers): show all matching containers in template builder dropdown (#30047)

[dsilvam]

Proposed Changes

• Fix DotContainersService.getFiltered() and getContainerByTitle() to send the page size as per_page (the REST endpoint's actual query param) instead of perPage. The mismatched name was silently ignored, so the server always fell back to its default page size of 10.
• Raise DotContainerOptionsDirective.maxOptions from 10 → 100 so the grouped container dropdown in the template builder shows all matching containers. The dropdown filters server-side as the user types, so this is the upper bound shown at once, not the total reachable.
• Update dot-containers.service.spec.ts URL assertions to per_page (they had been asserting the buggy URL).

Root Cause

The template-builder "add container" dropdown (p-select[dotContainerOptions]) only ever displayed the first 10 containers with no pagination or scroll-to-load. Two stacked defects: the ignored perPage param capped the server response at its default of 10, and maxOptions was hardcoded to 10 as well. Searching a term that matched more than 10 containers left the rest unreachable.

Checklist

• Tests (updated dot-containers.service.spec.ts; data-access service spec 15/15 and ui directive spec 2/2 pass)
• Translations
• Security Implications Contemplated — none; a client-side query-param rename aligning to the existing backend contract, no auth/permission changes.

Additional Info

• p-select has no clean server-side lazy-load-on-scroll, and it already filters server-side, so "show all (up to a generous bound, refine by typing)" is the appropriate fix for this control rather than infinite scroll.
• Known limitation: a single filter term matching more than 100 containers still truncates; typing narrows the server query so any specific container remains reachable.
• Separately noted latent bug (not addressed here): ContainerFactoryImpl.findContainers() caps totalResults at ~500 via its counting loop — worth a follow-up ticket for Sites with very large container counts.

Refs: #30047

🤖 Generated with Claude Code

This PR fixes: #30047

[claude]

Claude finished @dsilvam's task in 12m 59s —— View job

---

Rollback-Safety Analysis

• Read docs/core/ROLLBACK_UNSAFE_CATEGORIES.md
• Get PR diff (single commit ed656f71c, parent ed22589c5)
• Analyze diff against unsafe categories
• Post verdict (label applied)

Verdict: ✅ Safe to Rollback

The PR's actual changeset (3 files, +17/-14) is:

• dot-containers.service.ts — renames a client-side HTTP query param from perPage to per_page to match the REST endpoint's existing (unchanged) contract.
• dot-container-options.directive.ts — raises a local constant maxOptions from 10 to 100 (upper bound on dropdown options rendered client-side).
• dot-containers.service.spec.ts — updates test assertions to match the corrected URL.

No database migration, no Elasticsearch mapping/reindex, no data model change, no backend REST/GraphQL contract change (the server already expected per_page; only the frontend caller was fixed), no OSGi/VTL surface touched. This is a pure Angular frontend bugfix. If rolled back to N-1, the only effect is the pre-existing UI bug reappears (container dropdown truncated at 10 results) — no data loss, no startup failure, no broken persistent contract.

This does not match any category (C-1–C-4, H-1–H-8, M-1–M-4) in docs/core/ROLLBACK_UNSAFE_CATEGORIES.md.

Label AI: Safe To Rollback has been applied.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request