fix: Subscribed Views Handling

[Xavier-Charles]

Problem: Verasity board wasn't appearing in the Views Tab when navigating to /b/verasity/. Root Cause: The addViewToCache function was adding subscribed views to viewsCache only, but the Views Tab reads from subscribedViewsCache. The architecture maintains two separate caches for subscribed views:
subscribedViewsCache (minimal metadata) - used by Views Tab
viewsCache (full data) - used for sort order calculation
Solution: Modified addViewToCache in [useView.ts:263-271] to populate both caches for subscribed views:

if (isSubscribed) {
    dispatch(viewsStore.updateSubscribedViewsCache([view])); // For Views Tab
    dispatch(viewsStore.setViewsCache({                       // For sort order
        ...viewsCache,
        [view.id]: { ...remoteViewAsCachedView(view) },
    }));
    return;
}

This ensures subscribed views appear in the Views Tab while maintaining the full data needed for other operations.

[Copilot]

Pull request overview

This PR fixes an issue where subscribed views weren't appearing in the Views Tab when navigating directly to their URLs (e.g., /b/verasity/). The root cause was that subscribed views were only being added to viewsCache (full data) but not subscribedViewsCache (preview metadata) which the Views Tab reads from.

Key Changes:

• Modified addViewToCache in useView.ts to update both subscribedViewsCache and viewsCache for subscribed views, ensuring immediate visibility in the Views Tab
• Added fallback selection logic in useViewUpdater.ts to handle cases where a view is resolved from the backend but not yet in the cache (e.g., shared/public boards on first visit)
• Minor refactoring in useResolvedView.ts and useViewUpdater.ts for improved code clarity

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
packages/frontend/src/api/hooks/useView.ts	Modified addViewToCache to update subscribedViewsCache in addition to viewsCache for subscribed views; refactored subscribedViews memo for clarity
packages/frontend/src/api/hooks/useViewUpdater.ts	Added fallback selection logic for resolved views not yet in cache; refactored shouldAddToCache logic; removed debug logging
packages/frontend/src/api/hooks/useResolvedView.ts	Minor refactoring: extracted query params into a variable for better readability

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This line passes a TRemoteUserView (full view with widgets, keywords, max_widgets, language, etc.) to updateSubscribedViewsCache, which expects TUserViewPreview[] (lightweight preview data). While TypeScript allows this due to structural typing, it violates the architectural separation where subscribedViewsCache should contain minimal metadata (id, hash, name, slug, icon, and base fields only) while viewsCache holds full data.

This causes unnecessary memory usage by storing large data structures (widgets arrays, keywords) in subscribedViewsCache. Extract only the preview fields from the full view before calling updateSubscribedViewsCache, similar to how remoteSubscribedViews already populates this cache with lightweight data in useViewUpdater.ts (lines 272-281).