Allow web URL imports via the share extension

[matalvernaz]

Summary

Lets users share an http(s) URL pointing at a media file (e.g. an mp3 served by a self-hosted yt-dlp UI, a podcast episode link, a casting tool's direct download URL) into BookPlayer through the iOS share sheet. Today the share extension is hidden from the share sheet for URL-only payloads, since its activation rule only matches public.audio / public.folder / public.movie / com.pkware.zip-archive attachments — and even if it weren't, the rest of the pipeline assumed file URLs that the extension could copyItem straight into the shared folder.

Architecture

The share extension's NSExtensionActivationRule accepts public.url in addition to its existing UTIs. When a web URL arrives, the extension downloads it via a background URLSession with sharedContainerIdentifier set to the app group, then immediately calls completeRequest(returningItems: nil) — the share sheet dismisses without blocking on the download.

Two delegate paths cover the lifecycle:

• BackgroundDownloadCoordinator (in ShareViewController.swift): retained on the running view controller for as long as the extension's process is alive. iOS routes the URLSession(_:downloadTask:didFinishDownloadingTo:) callback to this delegate when the download completes while the extension is still running (typical for small files that finish in seconds). The coordinator moves the temp file into DataManager.getSharedFilesFolderURL().
• BackgroundShareDownloadDelegate (in AppDelegate.swift): the fallback for downloads large enough to outlive the extension. iOS launches the main app via application(_:handleEventsForBackgroundURLSession:completionHandler:), which recreates a session under the same Constants.shareExtensionBackgroundSessionIdentifier and lets this delegate move the temp file into the shared folder.

Either way, the file lands in the app group's shared folder, and BookPlayer's existing ImportManager pipeline picks it up on the next foreground via notifyPendingFiles() and the DirectoryWatcher already wired to that folder. The user sees BookPlayer's standard import-and-place flow, identical to AirDrop.

File-URL shares (AirDrop, Files, document picker) are unchanged: the extension still copies them directly into the shared folder.

URL filtering

To avoid showing BookPlayer in the share sheet for arbitrary web pages it couldn't actually download as audio, web URLs are pre-filtered by path extension against a small allow-list of audio / movie / archive formats: mp3 m4a m4b aac flac ogg opus wav wma aiff aif caf mp4 m4v mov zip. File URLs are accepted unconditionally — the import pipeline handles MIME sniffing.

Why background URLSession + delegate, and not the obvious alternatives

Earlier iterations tried each of these and ran into problems documented in the commit history:

• Open the host app via bookplayer://download?url=… URL scheme. Doesn't work on iOS 18+: the responder-chain openURL: walk no-ops with a system warning, and NSExtensionContext.open(_:completionHandler:) is documented Today-widget-only and confirmed to return false for share extensions.
• Foreground URLSession.downloadTask inside the share extension, then completeRequest. Works, but the share UI hangs for the duration of the download.
• Queue the URL into shared UserDefaults, drain in the main app via SingleFileDownloadService. Required main-app code to fire on warm-foreground via scenePhase, raced with DocumentFolderWatcher to produce duplicate import dialogs, and ultimately couldn't be made to land files reliably without bypassing significant chunks of the existing pipeline.
• Background URLSession in the extension with delegate: nil. This was the most subtle failure. The session created the download task and nsurlsessiond finished it correctly — but iOS only escalates background-session completion to the main app's matching-identifier session via handleEventsForBackgroundURLSession when the owning process is no longer running. For small downloads that complete in a few seconds, the share extension's process was still alive when the completion fired, so iOS routed the didFinishDownloadingTo event to the alive process's session — which had no delegate — and silently discarded the temp file. The two-delegate setup in this PR covers both lifecycles.

Test plan

• Compile-check on iOS device target
• End-to-end share from Safari to a real https://…/song.mp3 URL on iOS 26: file lands in shared folder, ImportManager surfaces it on next foreground, review and placement dialogs fire as for AirDrop, file imports into the library
• Confirmed via idevicesyslog that the share extension's BackgroundDownloadCoordinator fires didFinishDownloadingTo and moves the temp file
• File-URL shares (AirDrop, Files) unchanged — covered structurally by items.filter { $0.isFileURL } keeping the original copyItem path
• Long-running download outlives the extension — falls through to the main-app BackgroundShareDownloadDelegate. Believed-correct from spec; not exercised in testing because typical share-sheet payloads are small.

Known limitations

• iOS share-extension activation rules can predicate on UTI only, not URL content, so we filter inside the extension by path extension. BookPlayer will appear in the share sheet for any URL whose path happens to end in one of the allow-listed extensions even if the host is unrelated (rare in practice). Pages whose URL has no media-y extension won't show BookPlayer at all.

[matalvernaz]

Caught up to current develop. Same six commits as before, just rebased — nothing else to see.