feat(cohort): split cohort detail into Review and Edit tabs [2/2]

[chitrakshbotwala]

Part 2 of 2 of merging application review into the cohort screens (follow-up to the review screens that already landed in main).

What this PR does

Splits the cohort detail screen (/admin/cohort/[id]) into two tabs, selected via ?view=review|edit:

• Review (default): the cohort year's application list with status filters (Pending / Approved / Not approved) and approve/reject actions.
• Edit: the question editor (add / reword / reorder / remove / required toggle) and the end-cohort control.

Single-file change — reuses the existing .filter-tab styling, no new CSS.

Checks

format:check, lint, typecheck, test:unit, and build all pass locally.

[vercel]

@chitrakshbotwala is attempting to deploy a commit to the codenamed22's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Gotnochill]

Summary:

Both DB queries run unconditionally even on the Edit tab

Details:

The Promise.all([findMany, groupBy]) block always executes regardless of view. When view === "edit" , neither applications nor countByStatus is used anywhere in the Edit JSX: both results are fetched and immediately discarded. The findMany includes a join across user and profile, so on a cohort with many applicants this is meaningful wasted work on every Edit tab load.

Fix:

Guard the queries on the active view:

const [applications, counts] = view === "review"
  ? await Promise.all([prisma.application.findMany(...), prisma.application.groupBy(...)])
  : [[], []];

[chitrakshbotwala]

Edit page unnecessary DB queries: Only query when view === "review"; otherwise return [[], []]. findMany/groupBy no longer run on the Edit page.

[Gotnochill]

Summary:

Outer Review/Edit tab links don't preserve ?status=

Details:

The outer nav links are ?view=review and ?view=edit with no status param. If an admin is on
?view=review&status=approved and clicks Edit then Review , they land on ?view=review with no status param, defaulting back to Pending via STATUS_TABS[0] . Every Edit round-trip silently resets the status selection.

Fix:

carry the current status forward on the outer tab links:

href={`/admin/cohort/${cohort.id}?view=review&status=${activeStatus.key}`}
// Edit tab:
href={`/admin/cohort/${cohort.id}?view=edit&status=${activeStatus.key}`}

[chitrakshbotwala]

Status lost when switching tabs: Both links now include &status=${activeStatus.key}, so the selected status is preserved when navigating between Review and Edit.

[chitrakshbotwala]

pls review @Gotnochill all tests pass and fixes implemented

[Gotnochill]

Both queries run even when view === "edit", where neither applications nor countByStatus is used. The findMany with include: { user: { profile: true } } is the expensive one — every Save/Move interaction on the Edit tab triggers a full join for nothing. Guard these behind the view:

const [applications, counts] = view === "review"
   ? await Promise.all([prisma.application.findMany(...), prisma.application.groupBy(...)])
   : [[], []];

[Gotnochill]

The Review and Edit tab links don't carry ?status= forward. If an admin is on ?view=review&status=approved, clicks Edit, then clicks Review, they land back on Pending (the default). Every Edit round-trip silently resets the status filter. Suggest forwarding activeStatus.key:

href={`/admin/cohort/${cohort.id}?view=review&status=${activeStatus.key}`}
// and for Edit:
href={`/admin/cohort/${cohort.id}?view=edit&status=${activeStatus.key}`}