Notification secrets (accessToken) are returned to the client in API responses

**Describe the bug**

Notification credentials are returned to the client in API responses. When a notification is created, fetched, or edited, the response includes the stored `accessToken` (the provider secret) in plaintext for **matrix, telegram, twilio, and pushover**. So a stored secret round-trips to the browser on every fetch, and the edit form even relies on reading it back to repopulate the token field. Secrets should be write-only: stored and used to send, but never returned.

**To Reproduce**
1. Create a notification with a secret (e.g. a **telegram** channel with a bot token), via the UI or `POST /api/v1/notifications`.
2. Fetch it: `GET /api/v1/notifications/{id}` (or `GET /api/v1/notifications/team`).
3. In the response JSON, `data.accessToken` contains the bot token in plaintext.
4. Same in the browser: opening the notification's **edit** form triggers that GET and loads the secret into the client.

**Expected behavior**

The API should never return credential fields (`accessToken`, and any future secret) in responses. They should be store-and-use only: used when sending notifications, but never sent back to the client.

**Screenshots**

**Desktop (please complete the following information):**

Not applicable. This is server-side API behavior, reproducible with any client (curl or Swagger `/api-docs`), and also observable in-browser via the edit form's GET response.

**Additional context**
- **Severity:** authenticated and team-scoped (only members who manage the notification receive it), so the practical risk is client-side exposure such as XSS, the Network tab, or logs. It is a defense-in-depth hardening, not a remote exploit.
- **Context from #3717:** while discussing ntfy auth, @ajhollid asked that provider secrets not be returned to the client from the API. @mospell then noted that this already happens for the existing providers (the Matrix access token is returned alongside the other notification settings) and suggested filing it as its own issue. This is that issue.
- **The fix is coordinated fullstack:** the edit form currently depends on reading the token back to repopulate, so redacting the API also needs a frontend change (don't prefill the secret; a "re-enter to change / leave to keep" pattern).

Happy to help with this!

P.S. I saw a similar credential-exposure issue was recently handled as a security advisory; if you'd prefer this to go through that process too, happy to close this and re-report it privately.

Reproduce the exposure with curl or Swagger at /api-docs using POST /api/v1/notifications and the GET notification endpoints, then trace the server handlers and the notification edit form. Done means responses omit accessToken and the edit flow no longer pre-fills the secret while still supporting unchanged credentials and re-entry to change them.

Written by the indexing model from the issue text.