[6.x] Fix cache invalidation when using custom fields in URI route

[duncanmcclean]

This pull request fixes an issue where structured entries using custom fields in their route (e.g. {test}) would have stale URIs after saving.

This was happening because CollectionStructure::entryUri() retrieves a Page from cached flattenedPages, and that Page caches its routeData on the instance. When the entry is saved with updated field values, the same Page object is reused with stale route data, causing the URI to reflect the old field value instead of the new one.

This PR fixes it by:

• Calling $page->setEntry($entry) in CollectionStructure::entryUri() to ensure the page uses the fresh entry being saved
• Resetting the cached routeData and structure-uris blink in Page::setEntry() so stale values are discarded
• Replacing the makeItemFromFile() call in CollectionEntriesStore::writeItemToDisk() with a direct YAML ID parse, avoiding a side effect that put stale entries into the structure-entries blink store
• Fixing empty($ids) checks in updateEntriesWithinIndex() and updateEntriesWithinStore() to use collect($ids)->isEmpty(), since empty() always returns false for Collection objects

Fixes #14145

[jasonvarga]

Heads up on one bundled-but-unrelated change: switching empty($ids) → collect($ids)->isEmpty() in updateEntriesWithinIndex/Store is correct (since empty() always returns false for Collection objects), but it does change behavior for one case:

• Before: passing an empty Collection was a silent no-op — neither branch ran.
• After: an empty Collection is treated the same as null/[] and triggers a full $index->update() rebuild.

No current caller hits this — updateChildPageUris() and UpdateStructuredEntryUris::handle() both guard with their own isEmpty() early return — so this is safe today. Just worth being aware of in case a future caller passes an empty Collection expecting the old no-op semantics.