fix: resolve epic field showing unset when a task's epic isn't yet paginated

[pikann]

Summary

• Fixed the epic field silently rendering as unset (—) on task cards/rows and the task detail page whenever a task's epic wasn't among the first pages loaded by Feature/implement pagination for epic picker #336's cursor-based epic pagination (20/page). The badge/field was resolved with epicTasks.find(...) against that paginated array, so any epic past whatever window happened to be loaded looked like "no epic" even though the task had one.
• InteractionLayout now diffs the epics referenced by on-screen tasks against the loaded epic pages, fetches whichever ones are missing directly (reusing the existing single-task query, so no duplicate requests when that task is already cached), and merges them into the epics list passed down to board/list views.
• Task detail's PropertiesPanel had a second-order version of the same bug: it already fetches the task's parent directly (parentTask) for the "parent task" fallback field, but classified "is this parent an epic" by checking membership in the paginated epicTasks array. When the epic wasn't loaded, a task's real epic wasn't just unset — it was misrendered as a generic non-epic "Parent" field. Fixed by checking parentTask.task_type_id against the epic type directly instead of paginated-list membership.
• Audited every other .find()-based relationship lookup in the app (statuses, task types, members, custom fields, sprints, roles, doc folders, plugins) — all resolve against fully-loaded, non-paginated lists, so epics were the only entity with this failure mode.

Test plan

• tsc -b clean
• biome check clean
• vitest run on task-card.test.tsx / board-view.test.tsx — 21/21 passing
• Manual click-through in a browser before merge (no browser session available in this environment)

[pullfrog]

✅ No new issues found.

Reviewed changes — fixes the epic field silently rendering as unset when a task's epic is beyond the first 20 paginated results from #336, and corrects the parent-field classification that accidentally showed an epic as a generic "Parent" for the same reason.

• Merge missing epics into displayEpics in InteractionLayout — diffs on-screen task parent_task_id values against loaded epicTasks, fetches missing epics individually via taskQueryOptions + useQueries, and merges them after confirming task_type_id === epicType?.id (so non-epic parents don't masquerade as epics).
• Fix epic fallback in PropertiesPanel — falls back to parentTask (always fetched directly) when epicTasks.find(...) misses due to pagination, and switches the parent-field gating from !epicTasks.find(...) to a direct parentTask.task_type_id !== epicTypeId check.

Review notes

The missingEpicIds computation iterates all on-screen tasks and checks parent_task_id — this can include non-epic parents (story/task nesting), which triggers unnecessary taskQueryOptions fetches. These are filtered out by the displayEpics memo so they never reach the UI, and the redundant network calls are cheap and bounded by the visible task count. No action needed.

The parentTask query comment in task-detail/index.tsx:150 ("for non-epic parents") is now slightly stale since parentTask is also used for epic fallback, but this is a pre-existing comment, not part of the diff.

  ^{｜ View workflow run ｜ Using DeepSeek Pro (free via Pullfrog for OSS) (Kimi K2 not used — the program covers this model; add its provider key to run your pick) ｜ 𝕏}