Jira receiver: reopen_duration is not applied when alerts fire, contradicting its documentation

## Summary

The Jira receiver's `reopen_duration` setting has no effect on the decision that its documentation says it controls: whether a firing alert **reopens** a recently-closed issue or **creates a new one**.

## Documented behavior

From the [Grafana Jira contact point docs](https://grafana.com/docs/grafana/latest/alerting/configure-notifications/manage-contact-points/integrations/configure-jira/):

> **Reopen Duration** — The time duration (in minutes) to control whether to reopen an issue that was closed within this duration or create a new one. If not specified, the most recent issue that matches the deduplication key will be updated and reopened (if reopen transition is specified).

## Actual behavior

In `receivers/jira/v1/jira.go`, `getSearchJql` applies `ReopenDuration` only on the **resolved** path (`firing == false`), where it scopes the search for the issue to transition to resolved (the area recently touched by #543). On the **firing** path — the path that decides reopen-vs-create — the duration is never consulted:

- `reopen_transition` unset → `statusCategory != Done` (open issues only; closed issues always yield a new issue).
- `reopen_transition` set → **no status or age constraint at all**: the most recent issue matching the dedup key is found and reopened, no matter how long ago it was closed. `reopen_duration` is ignored.

The documented "reopen if closed within this duration, otherwise create a new one" behavior therefore never occurs.

## Reproduction

Grafana 12.3.1 (self-hosted), Jira Cloud. Contact point configured with `reopen_transition` set and `reopen_duration: 10m`. A firing alert whose issue had been closed **17 minutes earlier** reopened that issue; per the documentation a new issue was expected.

## Expected

When `reopen_transition` and `reopen_duration` are both set, the firing-path search should match only open issues or issues resolved within the duration, e.g. `(statusCategory != Done OR resolutiondate >= -10m)` — so older-closed issues fall out of the match and a new issue is created. With `reopen_duration` unset, current behavior (reopen the most recent match regardless of age) is what the docs describe as the fallback and should be preserved.

I have a PR ready implementing this and will link it here.

Read receivers/jira/v1/jira.go, focusing on getSearchJql and the separate firing and resolved paths. Verify how ReopenDuration is currently applied, then confirm the firing search preserves the unset-duration fallback while excluding older closed issues when a duration is configured; validate the behavior with the relevant Jira receiver tests.

Written by the indexing model from the issue text.