Drop FullCalendar's nonexistent dayGridClassNames option

[myabc]

Ticket

No work package. Frontend test-output hygiene, following up on #24622.

What are you trying to accomplish?

Removes the Unknown option 'dayGridClassNames' warning that FullCalendar logs every time the time-entry calendar or the work package calendar renders. It shows up six times in the te-calendar specs and also in the browser console in production.

There is no behavior change. Non-working days are still marked through dayHeaderClassNames, dayCellClassNames, slotLaneClassNames and slotLabelClassNames.

What approach did you choose and why?

FullCalendar 6 has no dayGridClassNames hook. The class-name hook for day-grid cells is dayCellClassNames, which both calendars already set to the same callback. The CalendarOptionsWithDayGrid interfaces only existed to let the unknown key typecheck, so they go too, and both option objects are typed as plain CalendarOptions.

AI involvement

Directed – I specified the requirements and AI implemented most of it; I validated via testing rather than a full line-by-line review.

Merge checklist

• Added/updated tests — n/a, fc-non-working-day is already asserted by the calendar, team planner and My page feature specs
• Added/updated documentation in Lookbook (patterns, previews, etc) — n/a
• Tested major browsers (Chrome, Firefox, Edge, ...) — not yet

[github-actions]

Warning

This pull request does not link an OpenProject work package.

Please add a link to the work package in the description, or reference it in the
title in square brackets, e.g. [SLUG-123] My title here.

[Copilot]

🟢 Approval recommended

No unresolved review issues remain.

Pull request overview

Removes FullCalendar’s unsupported dayGridClassNames option and related workaround typings, eliminating warnings while preserving non-working-day styling.

Changes:

• Removes the invalid option and obsolete interfaces/imports.
• Uses standard CalendarOptions typing.
• Retains supported class-name hooks.

File summaries

File	Description
frontend/src/app/features/calendar/te-calendar/te-calendar.component.ts	Removes the unsupported option and workaround type.
frontend/src/app/features/calendar/op-work-packages-calendar.service.ts	Removes the same option and custom interface.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/work_packages/batch_selection_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25362, linked for reference only):

- `rspec ./modules/backlogs/spec/features/work_packages/batch_selection_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #25362. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25362 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.