[Feature Request] Support multiple authentication methods for infrastructure monitors

**Is your feature request related to a problem? Please describe.**

Infrastructure monitors currently provide a single **Authorization secret** field. When configured, Checkmate always sends this value as a Bearer token:

`Authorization: Bearer `

This limits infrastructure monitoring to endpoints that accept Bearer authentication. Capture-compatible endpoints may be deployed behind reverse proxies, gateways, or other security layers that use authentication methods such as HTTP Basic Authentication or API keys.

Users currently need to change their existing security configuration or introduce an additional proxy that translates authentication headers.

**Describe the solution you'd like**

Add an **Authentication method** selector to the Create/Edit Infrastructure Monitor form with the following options:

- **Bearer Token** — the current behavior and default option
- **Basic Auth** — displays username and password fields
- **API Key** — displays configurable header name and value fields

Checkmate should construct the outgoing request according to the selected method:

- Bearer Token: `Authorization: Bearer `
- Basic Auth: `Authorization: Basic `
- API Key: `: `

Existing infrastructure monitors that already contain an authorization secret should continue to use Bearer authentication without requiring migration or manual reconfiguration.

Authentication credentials should be treated as sensitive values and must not be exposed in logs or error messages.

**Describe alternatives you've considered**

Configuring a separate reverse proxy to translate authentication headers is possible, but it adds deployment complexity and requires users to maintain additional infrastructure.

Embedding credentials in the endpoint URL was also considered, but explicit authentication fields are clearer and avoid placing credentials directly in URLs.

**Additional context**

Checkmate already constructs Bearer and Basic Authentication headers for the ntfy notification provider. If this request is accepted, the existing header construction logic could be moved into a small shared HTTP authentication helper and reused by both the ntfy and infrastructure request paths, avoiding duplicate implementations.

The existing Bearer authentication behavior should remain the default for backward compatibility.

If this feature request is accepted, I would be happy to work on the implementation.

I would appreciate @gorkem-bwl's input on the product direction and @ajhollid's feedback on how this would best fit the existing implementation.

Start with the Create/Edit Infrastructure Monitor form and the infrastructure request path, then review the existing Bearer and Basic header construction in the ntfy notification provider. The work is done when Bearer remains the default for existing monitors, Basic Auth and API Key requests are supported, and credentials are absent from logs and errors.

Written by the indexing model from the issue text.