feat(calendar): add Agenda view (chronological list of events + tasks)

[eibrahim]

Summary

Adds an Agenda view to the calendar (issue #88): a date-grouped, chronological list of upcoming events and scheduled tasks, rendered with FullCalendar's listWeek view and selectable alongside Day / Week / Month / Year. The Motion-style reference in the issue is exactly this - a scrollable list to scan what's coming up.

The "agenda" value was already declared in the CalendarView type union but no view rendered it (it silently fell through to the Year view); this wires it up.

What changed

• New AgendaView (src/components/calendar/AgendaView.tsx): uses @fullcalendar/list (listWeek), reuses the shared getAllCalendarItems() data source, enabled-feed filtering, click-to-quick-view, user time-format settings, and an empty-state message - mirroring the existing view components.
• New pure helper (src/lib/calendar-agenda.ts): formatAgendaItems holds the item-shaping / feed-filtering / sort logic so it is unit-testable without rendering FullCalendar; resolveEventDeleteMode makes the agenda's quick-view delete strictly safer (only the recurring master deletes as series; an expanded occurrence deletes as single).
• Header wiring (src/components/calendar/Calendar.tsx): adds the Agenda button and a render branch for view === "agenda"; prev/next navigation steps by week (consistent with Week view).
• Dependency: adds @fullcalendar/list@^6.1.15 (pinned to 6.1.15 to match the other @fullcalendar/* packages) to package.json + lockfile.
• OpenSpec: change issue-88-agenda-view created, validated, and archived to openspec/changes/archive/2026-06-22-issue-88-agenda-view/ (spec folded into openspec/specs/calendar-agenda-view/).
• CHANGELOG updated under [unreleased].

Test plan

• npm run test:unit - new src/__tests__/calendar-agenda.test.ts (12 tests) passes: feed filtering (tasks always included, disabled/missing feeds excluded), color resolution + fallbacks, extendedProps preservation, class names, chronological sort, and resolveEventDeleteMode (non-recurring -> single, occurrence -> single, master -> series). (The 2 pre-existing google-* timezone suites fail identically on origin/main and are unrelated.)
• npm run type-check - clean.
• npm run lint - clean (zero warnings).
• Manual: select Agenda from the header; the upcoming events + scheduled tasks render as a date-grouped list; clicking an item opens its quick view; an empty range shows the empty-state; prev/next steps by week.

Codex review

Codex adversarial-review was run in a loop. Two findings were fixed in-scope (recurring-occurrence delete no longer escalates to whole-series for the direct delete path; the global new-event command now works while the agenda is active).

The final verdict is needs-attention solely due to two PRE-EXISTING bugs in shared code that are not introduced by this diff and affect all five calendar views (not just the agenda) - they are out of scope for this additive feature and are tracked separately:

• Recurring-occurrence delete escalates to the whole series (all calendar views) #198 - Recurring-occurrence delete escalates to the whole series (EventModal.tsx:211 //todo forces editMode = "series"; reached via Edit -> Delete in every view).
• Google single-event delete removes the wrong instance (next upcoming, not the clicked one) #199 - Google single-event delete removes the wrong instance (deleteGoogleEvent uses timeMin: now / maxResults: 1 instead of the clicked instance; also reached via task-block-push.ts).

This PR is strictly safer than the status quo for the surface it adds. Per maintainer direction, it is opened without a clean Codex approve because the only blocking findings are these pre-existing, out-of-scope shared bugs.

Note: do not auto-merge - this needs Emad's sign-off given there is no clean Codex approve (blocked solely by pre-existing out-of-scope findings #198 / #199).

Closes #88

🤖 Generated with Claude Code

https://claude.ai/code/session_016mqdsn2va7teLRuNPdyeZy

[eibrahim]

Claude /code-review (review-only; NOT merging)

Reviewed the full diff against origin/main in a dedicated worktree. Branch is already up to date with main (git merge origin/main -> "Already up to date").

Verdict: no NEW blocking issues introduced by this PR.

The change is purely additive (762 insertions, 0 deletions across 13 files; the only touched shared file is Calendar.tsx, which gains an agenda button + render branch). CalendarView already includes "agenda", so setView("agenda") is type-safe.

What's good

• formatAgendaItems faithfully mirrors the inline event-mapping in DayView/WeekView (color fallbacks #4f46e5/#3b82f6, calendar-task/calendar-event classNames, getEventEditability, extendedProps), but pulled out as a pure function so it's unit-testable without rendering FullCalendar. 12/12 new unit tests pass.
• Disabled/missing-feed filtering matches the other views; tasks (feedId === "tasks") always included.
• resolveEventDeleteMode is actually more correct than the existing inline logic in DayView/WeekView. Those escalate any recurring occurrence to a series delete (isRecurring ? "series" : "single"), whereas Agenda only escalates the recurring master to "series" and deletes occurrences as "single".

Gates (run in worktree, deps installed):

• npx jest src/__tests__/calendar-agenda.test.ts -> 12 passed
• npm run type-check -> clean
• npx next lint --max-warnings=0 on the changed files -> no warnings or errors

Out-of-scope, pre-existing (NOT introduced here)

The Agenda view still routes deletes through the shared store/backend, so it inherits two pre-existing bugs that affect all five calendar views and are tracked separately:

• Recurring-occurrence delete escalates to the whole series (all calendar views) #198 recurring-occurrence delete escalates to whole series (EventModal/store layer).
• Google single-event delete removes the wrong instance (next upcoming, not the clicked one) #199 Google single-event delete removes the wrong instance (deleteGoogleEvent uses timeMin: now / maxResults: 1).

These are out of scope for this additive feature and are why the adversarial review returns needs-attention rather than a clean approve.

Not merging - leaving this open pending maintainer manual sign-off (no clean Codex approve because of the pre-existing #198/#199 findings).