feat: add authentication support to ntfy notifications

[egeoztass]

Closes #3717

One open question before you read the diff

@ajhollid — I asked this on #3717 but it's probably easier to answer here.

Where should the basic-auth password live? This PR reuses the existing accessToken field as the single credential (bearer token when ntfyAuthType is token, password when it's basic), rather than adding a dedicated ntfyPassword. The upside is that no new secret field enters the codebase, so it inherits whatever credential handling already exists and stays compatible with #3803. The downside is that accessToken holding a basic-auth password reads a little oddly.

If you'd rather have an explicit ntfyPassword, say so and I'll switch it — it's a rename across five files and the tests already cover the behaviour, so it's cheap to change. I went ahead and built it rather than leave the issue sitting, since several people on the thread are blocked on this.

Problem

NtfyProvider posts to {address}/{topic} with only Title, Priority and Tags headers — no Authorization at all. Any ntfy server that requires auth rejects every alert, and the provider catches the error and returns false, so the channel silently never delivers. From the issue thread: "Ntfy alerts are simply not working at the moment."

Change

Adds ntfyAuthType — "none" | "token" | "basic" — mirroring the webhookAuthType discriminator shape from #3785:

• token → Authorization: Bearer <accessToken>
• basic → Authorization: Basic base64(ntfyUsername:accessToken)
• none (or unset) → no header, exactly as today

ntfyUsername is the only new field and it isn't a secret.

Two deliberate decisions:

Incomplete credentials fail the send rather than falling back to an anonymous post. If a channel is configured for auth but the credential is missing, posting anyway would publish to a topic the operator believes is protected. It logs and returns false instead.

Validation rejects partial auth config up front — basic without a username, token without a token, and credentials supplied while auth is off. This is aimed at the concern you raised on #3785 ("I can create invalid authentication schemas without them being rejected"). Issues are reported per-field so the client can map them.

Backend only, per your note on the issue that a backend implementation must come first and be fully tested. Frontend follows once this lands.

Conventions

• NtfyAuthTypes is a const tuple in notification.type.ts, reused for both the Zod enum and the Mongoose schema enum, per rules 8 and 10 in docs/coding-conventions.md.
• The refinement follows the refineStrategyType pattern from monitorValidation.ts.

Tests

23 cases in ntfyProvider.test.ts (up from 12) and 19 in notificationValidation.test.ts (up from 5), covering both auth types, header composition, every incomplete-credential combination, and the "no auth type" default.

npm test — 79 suites, 1361 tests passing. tsc --noEmit, eslint, prettier --check all clean, OpenAPI spec regenerated.

[ajhollid]

Solid implementation, thanks for your hard work!

RE the token field reuse, I think that's acceptable here, I don't see any need for a new field to be added.

Thanks again for your contribution!