Handle absolute calendar item action popup URLs

[DeBaschdi]

Summary

This fixes calendar_item_action.default_popup handling when the localized popup value is already an absolute URL.

The current implementation always passes the localized default_popup value through extension.getURL(). That works for relative manifest paths, but it breaks if localization or manifest processing already produced an absolute extension URL such as moz-extension://.../popup.html.

In that case, extension.getURL() treats the absolute URL as a path and prefixes it with the extension base URL again. The resulting popup URL contains a nested extension URL and points to a non-existing resource.

Example result:

moz-extension://<uuid>/moz-extension://<uuid>/popup.html

Opening the calendar item action popup then fails because Thunderbird tries to load that invalid URL.

What changed

The popup value is now localized first and then checked:

• absolute URLs are kept unchanged
• relative paths are still resolved through extension.getURL(...)

This keeps the existing behavior for normal relative default_popup manifest entries while avoiding invalid nested URLs for already resolved absolute popup URLs.

Why this fixes the issue

default_popup can validly be represented in two forms at this point:

• a relative extension path, for example ui/popup.html
• an already absolute URL, for example moz-extension://.../ui/popup.html

Only the relative form needs extension.getURL(). Calling extension.getURL() on an already absolute URL changes its meaning and creates an invalid resource path.

By preserving absolute URLs and resolving only relative paths, the calendar item action popup receives a loadable URL in both cases.