Claim Jira Forge installation id and client key across cells
What
Makes JiraConnectInstallation a Cells::Claimable model. It claims two attributes through the Topology Service, both behind cells_claims_jira_connect_installations (default off):
forge_installation_xid(CLAIM_TYPE_JIRA_FORGE_INSTALLATION_ID): how a FIT-authenticated native Forge request identifies the installation. The column is added in gitlab-org/gitlab!248685.client_key(CLAIM_TYPE_JIRA_CLIENT_KEY): how Connect lifecycle and iframe requests identify the tenant (the JWTiss). Not a fallback, since it covers the whole Connect request family.
Also adds a nullable updated_at, which Cells::Claims::VerificationService requires (same as pages_domains).
cloud_id is deliberately not claimed. A single Jira site legitimately maps to several installations, so tenant scope cannot carry a uniqueness constraint. See gitlab-org/gitlab!248685 for the reasoning.
Dependencies
gitlab-org/cells/topology-service!548 (merged) is merged. It adds the two claim types and the source type RAILS_TABLE_JIRA_CONNECT_INSTALLATIONS.
The vendored client gem in this merge request now comes from the Topology Service main branch, at revision 267fb06.
The forge_installation_xid column is merged in gitlab-org/gitlab!248685. This merge request targets master directly, so there is no chain left.
Rollout notes
One flag covers the rollout: cells_claims_jira_connect_installations, default off. Since gitlab-org/gitlab!251634, Cells::ClaimsVerificationWorker reads the model-specific flag instead of a per-model worker flag, so claim creation and verification share one switch.
forge_installation_xid is a new, empty column, so no deduplication and no backfill are needed.
client_key has no cross-organization duplicates in production (aggregate counts only, no data).
The rollout issue is gitlab-org/gitlab#624924.
How to verify
spec/cells/claims/jira_connect_installation_spec.rb plus the cells claimable model shared example in the model spec. Green in EE and FOSS_ONLY=1 (92 examples).