[ Bug]: Jira providers ignore ticket_creation_url and link tickets by the connection host

Describe the bug

Both Jira providers declare ticket_creation_url in their authentication config (keep/providers/jira_provider/jira_provider.py:53, keep/providers/jiraonprem_provider/jiraonprem_provider.py:43) and neither one reads it. That declaration is the only place the name appears in either file.

The link Keep hands back is built from the host the provider connects to (jira_provider.py:599 and :629, jiraonprem_provider.py:557 and :580):

result["ticket_url"] = f"{self.jira_host}/browse/{issue_key}"

Those two addresses are not always the same. Jira can sit behind a reverse proxy under another hostname, or Keep can reach it over a cluster-internal address that resolves nowhere else. Workflows put ticket_url on the alert through enrich_alert, so an address only Keep can reach then shows up in the UI and in every notification built from that alert.

To Reproduce

1. Configure the provider with host set to an internal address, say http://jira.internal:8080, and ticket_creation_url set to https://jira.company.com/secure/CreateIssue.jspa.
2. Run a workflow that creates or updates a ticket.
3. ticket_url comes back as http://jira.internal:8080/browse/KEY, which nobody outside the cluster can open.

Expected behavior

ticket_creation_url holds the public address, so the returned links use it as their base. The field points at the new-issue form, and Jira writes that link in several ways, so all of these should work: /secure/CreateIssue.jspa, /secure/CreateIssue!default.jspa?pid=10000&issuetype=1, either of them under a context path, and a plain base URL with or without a scheme. An empty field leaves today's behaviour in place.

Additional context

A PR implementing this follows.