feat(monitors): add request headers to HTTP monitors

[eralpozcan]

Describe your changes

Adds an optional list of key/value request headers to HTTP monitors. The configured headers are sent with every check, so endpoints behind an API key, a tenant header, a custom User-Agent, etc. can be monitored.

This picks up #3755, which was left unfinished when #3756 went inactive with review feedback still open. The work here is written against current develop and resolves the points that were still outstanding on that review:

• Invalid headers can no longer be accepted. Header names are validated as RFC 9110 tokens and values as printable ASCII (no CR/LF, no leading/trailing whitespace), on both the client and the server. Previously a header like X-Api Key or a value containing a newline would pass validation, get scheduled, fail at request time and report the monitor as down for no visible reason.
• Connection-level headers the HTTP client manages itself (host, content-length, transfer-encoding, connection, upgrade, keep-alive) are rejected for the same reason, as are duplicate header names (case-insensitive).
• No type casting in the form. The array-level error is read through form.getFieldState("headers", form.formState).error?.root, so the error object is not coerced with as.
• Rows are built from FormTextField / useFieldArray with stable field.id keys, and stack vertically on small screens.
• No editor artifacts: no BOM in the translation files, no .gitignore changes.

The existing secret field still owns the Authorization header — it is applied last and wins if a header of that name is also configured.

Server-side, headers is an optional subdocument array on the monitor, validated on create / edit / import and mapped back to plain pairs when reading.

Screenshots

Desktop:

Small screen (fields stack):

Tests

13 new unit tests covering the validation rules (invalid names, invalid values, reserved names, duplicates, optional/default behaviour) and HttpProvider header assembly (configured headers, merge with the secret-derived Authorization, secret precedence, no headers at all). Full server suite: 1516 passing.

Write your issue number after "Fixes "

Fixes #3755

Please ensure all items are checked off before requesting a review. "Checked off" means you need to add an "x" character between brackets so they turn into checkmarks.

• (Do not skip this or your PR will be closed) I deployed the application locally.
• (Do not skip this or your PR will be closed) I have performed a self-reviewing and testing of my code.
• I have included the issue # in the PR.
• I have added i18n support to visible strings (instead of <div>Add</div>, use):

const { t } = useTranslation();
<div>{t('add')}</div>

• I have not included any files that are not related to my pull request, including package-lock and package-json if dependencies have not changed
• I didn't use any hardcoded values (otherwise it will not scale, and will make it difficult to maintain consistency across the application).
• I made sure font sizes, color choices etc are all referenced from the theme. I don't have any hardcoded dimensions.
• My PR is granular and targeted to one specific feature.
• I ran npm run format in server and client directories, which automatically formats your code.
• I took a screenshot or a video and attached to this PR if there is a UI change.