Fix filter-bar regressions in calendar view and external feeds [#251]

[dgershman]

Closes #251

Follow-up bug-fix pass on the display filters reported after the 1.9.0 feature shipped.

Fixes

1. Selecting a filter reset the calendar to the current month.
The activeFilters effect clears events and flips loading, which tripped the list-level loading && !events.length early return and unmounted CalendarView — remounting reset its internal month state back to today. Now:

• CalendarView's displayed month is controlled by EventList's calendarDate (which is preserved across filter changes), so even a remount shows the navigated month.
• The list-level loading/error/empty early returns no longer fire in calendar view (the calendar renders from its own calendarEvents / calendarLoading), so the calendar stays mounted and just shows its loading overlay while events refetch.

2. Filter dropdown didn't auto-close on selection.
Toggling a value now closes the panel, so it stops covering the calendar. Combined with a slightly reduced panel max-height, this addresses long Service Body / Category lists covering the first days of the calendar.

3. External feeds ignored the Event Type filter.
Only categories was re-applied locally on external events; event_type was forwarded but a remote on an older Mayo (before event_type filtering existed) or a non-Mayo feed ignores it and returns every type. Added local re-enforcement of event_type (mirroring the existing categories block, #292), so filtering on Service actually hides Activity events from external feeds. Empty filter = no constraint.

Testing

• composer test — 550 tests pass (added 6 unit tests for the event_type matcher: include/exclude/mixed/empty).
• npm run build — bundles compile.
• Root-file PHPCS errors are pre-existing (unchanged with these changes stashed).