fix(files): keep reactivity when destructuring the store in grid view

[ELHart05]

• Follow-up to fix(files): keep reactivity when destructure store #59942, related to Viewer drops to parent when opening an image #59941

Summary

#59942 fixed FileEntry.vue but left FileEntryGrid.vue behind, so the same bug is still there in grid view on 34.

The grid entry destructures the store directly:

const {
	activeFolder,
	activeNode,
	activeView,
} = useActiveStore()

Those are plain values captured on the first render and never update again. FileEntryMixin.execDefaultAction hands this.activeFolder to the file action, the viewer builds its route from folder.path, and the list gets navigated to whichever folder was active back then.

Reproduced on 34.0.2 with the list in grid view, going into /Level1/Level2/Level3/Level4 and clicking a PDF:

pushState    /apps/files/files/79?dir=/Level1/Level2/Level3/Level4
replaceState /apps/files/files/80?dir=/&editing=false&openfile=true
replaceState /apps/files/files/80?dir=/Level1/Level2/Level3/Level4&editing=false&openfile=true

The first replace goes to dir=/, so the root is fetched and the file opens over the wrong listing. It corrects itself a moment later, but the wrong navigation has already happened, and that is the "dropped back at the root" from #59941. The same steps in list view keep the right dir the whole way.

Same storeToRefs change as #59942. The setup block already carried a // keep in sync with FileEntry.vue comment, which is what got missed.

FileEntryGrid.spec.ts covers it: it fails on master and passes with the change.

Worth backporting to stable34 and stable33, both are affected. Happy to request that once this looks good.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)