[6.x] Fix navigation collections array handling

[jackmcdade]

What This Fixes

This PR adds defensive Arr::wrap() calls in NavigationController to ensure that the collections value passed to views is always an array, even in edge cases.

Background

A customer reported getting a count(): Argument #1 ($value) must be of type Countable|array, string given error when clicking "Link to Entry" on a navigation item configured to allow linking to 2 collection types.

The original fix in #15177 (v6.27.2) addressed this issue in:

• Entries::getConfiguredCollections()
• EntryLinkType::collections()
• Collection filter scope's visibleTo() method

However, there may be edge cases where the collections value still needs additional defensive wrapping in the controller layer.

What Changed

Added Arr::wrap() around $nav->collections()->map->handle()->all() in:

• NavigationController::edit() (line 67)
• NavigationController::show() (line 141)

While ->all() on a Collection already returns an array, this defensive wrapping ensures that the value passed to JavaScript is always an array, regardless of any unexpected edge cases in the getter chain.

Tests

Added comprehensive tests in LinkToEntryWithMultipleCollectionsTest covering:

• Navigation with collections as an array (normal case)
• Navigation with collections as a string (YAML edge case)
• Navigation edit page with string collections
• Full flow through the page selector filters endpoint

Note for Customer

If the customer is still experiencing this issue on v6.27.2, they should:

1. Clear all caches: php artisan optimize:clear && php please stache:clear
2. Restart PHP-FPM / web server to clear any opcode cache (OPcache)
3. Verify their navigation YAML file has collections as an array: [pages, articles] not as a string
4. Check if they have any addons that might be interfering with navigation handling