JiraIssueChangelogItems primary key collision when Jira reports multiple items with the same field in one changelog entry

### Summary

`JiraIssueChangelogItems` has a composite primary key of `(ConnectionId, ChangelogId, Field)`. When Jira returns multiple items with the same `Field` value within a single changelog history entry, the second item silently overwrites the first on upsert.

### Steps to reproduce

1. Have a Jira issue where a single-value field (e.g. `fixVersions`) is changed from value A to value B in one action
2. Jira's API represents this as two changelog items in the same history entry:
- `Fix Version: null → B` (add)
- `Fix Version: A → null` (remove)
3. Both items share the same `ChangelogId` and `Field = "Fix Version"`
4. Run the Jira extractor — only one item survives in `_tool_jira_issue_changelog_items`

### Expected behavior

Both changelog items should be stored — the add and the remove.

### Actual behavior

The second item overwrites the first because they collide on the primary key `(ConnectionId, ChangelogId, Field)`.

### Impact

Any downstream query that relies on changelog items to detect whether a specific value was ever added to a field (e.g. filtering issues by historical `fixVersions`) will produce incorrect results. This affects `fixVersions`, `labels`, `components`, `affectedVersions`, and any other field where Jira emits multiple items with the same field name in one history entry.

### Suggested fix

Add a disambiguating column to the primary key — for example an item ordinal/index within the changelog entry. The model is in `backend/plugins/jira/models/issue_changelog.go`:

```go
type JiraIssueChangelogItems struct {
ConnectionId uint64 `gorm:"primaryKey"`
ChangelogId uint64 `gorm:"primaryKey"`
Field string `gorm:"primaryKey"`
// no item-level disambiguator
}
```

Existing data would need re-extraction after the schema change, since collided rows already lost one of the two items.

### Version

Verified on `v1.0.3-beta10` and confirmed the PK is unchanged on `main` as of 2026-08-17.

Start with backend/plugins/jira/models/issue_changelog.go, then trace the Jira extractor's upsert path for JiraIssueChangelogItems. Reproduce the two same-field items and inspect the schema-change implications; done means both items persist without collision after re-extraction, with regression coverage for the reported case.

Written by the indexing model from the issue text.