Fixes #872.
A webhook configured in Settings > Notifications never fired for a real event, for two independent reasons. Fixing either alone leaves the feature broken.
Vocabulary. The settings screen writes book-added, book-downloading, book-available and book-completed onto WebhookConfiguration.Triggers. The dispatch guard read Imported, Failed, System and Moved. No overlap, so the guard never passed.
Reach. The five call sites emitting the kebab names posted only to the legacy singular settings.WebhookUrl and never iterated settings.Webhooks. So even with the vocabularies reconciled, three of the four checkboxes would still have delivered nothing.
The four kebab names become canonical. They are the settings default, the migration default, what NotificationPayloadBuilder.Attachments.cs already compares against, and what the production call sites emit, so this direction moves the fewest live values. Comparison is case-insensitive and alias-aware, so a row storing the literal Imported still fires.
book-completed is emitted from import finalization, after the import commits and not again when a finished import is retried. It goes through the existing OnDownloadImportedAsync hook and is dispatched as book-completed, which is what the UI labels "Processing Complete". Moved is deliberately not mapped there too, since it is the library relocation job and collapsing the two would double-fire and mislabel.
Narrower than the issue described. #872 said option 2 also retires the legacy WebhookUrl. This does not, because that is a design call rather than part of the defect.
Behaviour change. Dispatch is unified, so an install with a legacy WebhookUrl stored will also start receiving book-completed, where before that target got three events. Completion notifications are now dispatched as book-completed instead of Imported, so the NTFY Tags header on those messages changes from Imported to `book...
Automated Canary build