Replace cal.createAdapter-based calendar observers with explicit calIObserver objects

[DeBaschdi]

Fixes #66

Summary

This PR replaces cal.createAdapter(Ci.calIObserver, ...) usage in the calendar experiment with explicit calIObserver objects using:

QueryInterface: ChromeUtils.generateQI(["calIObserver"])

Problem

On newer Thunderbird releases, cal.createAdapter is no longer available.

That breaks listener registration in the calendar experiment and prevents these experiment events from being registered correctly:

• calendar.items.onCreated
• calendar.items.onUpdated
• calendar.items.onRemoved
• calendar.calendars.onUpdated

Cause

The experiment currently relies on:

cal.createAdapter(Ci.calIObserver, { ... })

for internal observer creation.

When that helper is unavailable, observer registration fails before cal.manager.addCalendarObserver(observer) can succeed.

Fix

Replace the removed helper usage with explicit calIObserver objects.

The patch adds small local helpers which provide:

• QueryInterface: ChromeUtils.generateQI(["calIObserver"])
• no-op implementations for unused observer callbacks
• only the event-specific methods overridden where needed

This keeps the public experiment API unchanged and only updates internal observer construction.

Affected files

• calendar/experiments/calendar/parent/ext-calendar-items.js
• calendar/experiments/calendar/parent/ext-calendar-calendars.js

Verification

Verified manually on:

• Thunderbird ESR 140
• Thunderbird Release 149

After the patch:

• calendar.items.onCreated works
• calendar.items.onUpdated works
• calendar.items.onRemoved works
• calendar.calendars.onUpdated works
• the previous cal.createAdapter is not a function runtime errors are gone

Notes

This is a compatibility fix only.
It does not change the public experiment API surface or semantics.

[kewisch]

@mkmelin can you give this a quick look? I believe you removed createAdapter in core code.

[DeBaschdi]

One more note on downstream impact:

NC Connector depends on the persisted "browser.calendar.items.*" lifecycle events provided by this experiment layer. These events are not just used for UI updates, but for the add-on's post-save synchronization flow after a calendar item is actually created, updated, or removed.

In practice, that flow is used to keep Talk room metadata in sync with the saved event, persist the event↔room mapping, run deferred participant/delegation updates, and clean up associated Talk rooms again when an event is deleted.

So while restoring an equivalent helper in core would of course also help downstream consumers, this PR keeps the fix local and minimal by removing the experiment's remaining dependency on "cal.createAdapter()".

[mkmelin]

Seems ok to me, thanks!

[DeBaschdi]

createCalendarObserver() is added twice with the same implementation — should we move that into a shared helper?

[kewisch]

Yes I think you can put it in ext-calendar-utils.sys.mjs ?