[Atlassian Jira]: Scoped API tokens return empty records due to missing timezone in date format

### Integration Name

Atlassian Jira [atlassian_jira]

### Dataset Name

jira.audit

### Integration Version

1.31.0

### Agent Version

9.3.2

### Agent Output Type

elasticsearch

### Elasticsearch Version

9.3.2

### OS Version and Architecture

All (platform-independent, the issue is in the httpjson request date format, not OS-specific). Reproduced on macOS ARM64 (Apple Silicon), but affects any platform running Elastic Agent since the bug is in the API request formatting.

### Software/API Version

Jira Cloud Premium, Atlassian REST API v3 (via Cloud ID URL)

### Error Message

No explicit error, the integration shows as Healthy in Fleet and all API responses return HTTP 200. However, zero documents are ingested into Elasticsearch.

Request tracing reveals the Jira Audit API returns an empty `records` array when called through the Cloud ID URL with the integration's default date format:

```json
{"offset": 0, "limit": 1000, "total": 112, "records": []}
```

Note: the `total` field is misleading — it reflects the instance-wide audit record count, not the filtered result count.

### Event Original

Not applicable, this is not a pipeline/parsing error. The issue is at the HTTP request level: the API returns valid JSON with an empty `records` array, so no documents reach the ingest pipeline.

### What did you do?

Configured the Atlassian Jira integration (v1.31.0) on Elastic Cloud 9.3.2 (ap-southeast-2) using a scoped API token (Atlassian's new least-privilege token type).

Scoped tokens only authenticate against the Cloud ID URL format:
```
https://api.atlassian.com/ex/jira/{cloudId}/
```
They do not work with the traditional site URL (`https://yoursite.atlassian.net/`). Upscoped tokens with full admin access may still work with the site URL, but using them is a security risk in production environments.

Integration configuration:
- API URL: `https://api.atlassian.com/ex/jira/{cloudId}/` (required for scoped tokens)
- Authentication: Email + scoped API token (classic + granular scopes)
- All other settings: Defaults

The integration authenticated successfully and shows as Healthy in Fleet.

### What did you see?

Zero documents ingested. After enabling request tracing, I found the root cause is the **date format** in the `from`/`to` query parameters.

The httpjson config uses a Go time format that **omits the timezone**:
```
2006-01-02T15:04:05.999
```

This produces requests like:
```
from=2026-03-25T08:37:30.699
```

Testing the Jira Audit API through the Cloud ID URL manually:

| `from` parameter format | Records returned |
|---|---|
| `2026-03-25T08:37:30.699` (no timezone — what the integration sends) | **0 records** |
| `2026-01-01T00:00:00.000+0000` (with timezone offset) | **112 records** |
| No `from`/`to` params at all | **112 records** |

The same date format without timezone works fine against the traditional site URL — the issue is specific to the Cloud ID URL that scoped tokens require.

### What did you expect to see?

Audit records should be ingested successfully when using the Cloud ID URL with scoped API tokens. The API should receive properly formatted date parameters that include timezone information.

**Proposed fix:** Append `Z` (UTC timezone designator) to the Go time format in the httpjson request template:

```
// Current:
2006-01-02T15:04:05.999

// Fixed:
2006-01-02T15:04:05.999Z
```

This is a one-character change that would make the integration compatible with both the traditional site URL and the Cloud ID URL required by scoped tokens.

### Anything else?

Deployment: Elastic Cloud 9.3.2 in `ap-southeast-2`
- Token type: Atlassian scoped API token (both classic and granular scopes tested, same result)
- Workaround: None found via integration settings. The httpjson request template date format cannot be overridden through the Fleet UI or Processors config.
- Security context: Atlassian is pushing users toward scoped tokens as a best practice. The integration should support the Cloud ID URL format these tokens require, rather than only working with full-access upscoped tokens against the site URL.
- Potentially affects all `httpjson`-based Atlassian integrations that use date cursor parameters (Jira, Confluence, etc.).