fix(notify): make notification tests, delivery passes, and queued alerts reliable

[crypt0rr]

What changes

• One test message per destination. The global notification test sends one message to each deployment destination and each enabled web-managed destination. This applies to both the console and edgewatch notify test. The legacy SHA-256 alias of a deployment URL still routes outbox rows created before opaque IDs, but it no longer adds a second test send.
• Locked destinations fail the test. A web-managed destination is locked when the notification key is missing, replaced or unreadable. If an enabled destination is locked, the global test now fails with ErrManagedNotificationLocked. The error names the destination ID and lock reason, never its URL.
  • edgewatch notify test prints {"tested","failed","locked"}, exits non-zero and records operation=global status=failed.
  • POST /api/v1/notifications/test returns 503 notification_key_unavailable instead of 200 {"sent":0}. The success response shape is unchanged.
  • Paused destinations and an empty configuration still pass.
• The delivery pass window no longer kills sends. The daemon's 90-second window (Notifier.DrainWithin) now only stops new claims and dispatch.
  • Sends already running finish under the daemon context and the 15-second provider timeout. A slow but healthy provider is no longer killed, charged a deferral or delayed by 30 minutes.
  • Claims that never started are still released without using a retry budget.
  • Shutdown still cancels sends in flight.
• Schema 49: a rename no longer drops a queued alert. The new column managed_notifications.credential_revision records the revision that last changed a destination's credentials. When the alert's event transaction commits:
  • If the destination's credentials have not changed since the alert captured it, for example after a rename, the alert is queued under the current revision.
  • If the credentials changed or the destination was deleted, the alert is still discarded rather than sent to new credentials. The discard is audited as notifications.pending_discarded.
  • Existing rows are backfilled to their current revision.
• notification.key follows the database file. The default key path now comes from the normalized database file (Store.FilePath). A database: file:… URI no longer creates the key under the working directory. DefaultKeyPath accepts every DSN form, and memory databases have no key path.
• Docs. README.md and SECURITY.md describe:
  • the new notify test output and exit status;
  • rename versus credential-change behavior for queued alerts;
  • where the default key lives;
  • schema 49.

Why

• [P3] Notification test sends two messages to each deployment destination #776: the store-backed notifier registered each deployment URL under both its opaque ID and its legacy digest, and the test sent to every entry.
• [P3] notify test reports success when managed destinations are locked by a missing or wrong key #777: the global test silently skipped locked destinations. Verifying a restored key passed even when the key was wrong.
• [P3] Delivery pass deadline kills healthy in-flight sends and defers them for 30 minutes #778: the 90-second pass deadline was shorter than the real worst case for a 64-row pass, about 240 seconds. It killed in-flight provider children and deferred them as indeterminate.
• [P3] Renaming a managed destination while an alert is being queued silently drops that alert #779: alerts capture their managed destination revision before the event transaction. A rename in that window advanced the revision, and the insert then dropped the alert without an audit entry.
• [P3] notification.key is created relative to the working directory for file: database URIs #780: notify.New derived the key path from the raw DSN. A file: URI therefore produced a relative file:/… path under the process working directory.

Validation

• Every issue has a regression test that fails on the previous code for the reported reason.
• go test -race -count=1 passes for internal/notify, internal/store, internal/app, internal/web and cmd/edgewatch.
• go vet ./..., gofmt and the pinned golangci-lint (--new-from-rev=origin/main) are clean.
• ./scripts/check-schema-docs.sh reports schema 49.
• Go changed-line coverage is 92.35%.
• The migration 49 table guard matches the original managed_notifications definition.
• Frontend and e2e suites were not run: this PR changes no frontend code or browser flows.

Compatibility

• Schema 49 is forward-only. An older binary refuses the upgraded database.
• The console notification test returns 503 when an enabled web-managed destination is locked.
• edgewatch notify test now prints a JSON summary and exits non-zero in that case.

Closes #776
Closes #777
Closes #778
Closes #779
Closes #780