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

从 backend/plugins/jira/models/issue_changelog.go 开始，然后跟踪 Jira extractor 针对 JiraIssueChangelogItems 的 upsert 路径。复现两个具有相同字段的 item，并检查 schema 变更的影响；完成标准是重新提取后两个 item 都能无冲突地持久化，并为报告的案例提供 regression coverage。

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:

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.