Draft: Share the job definition record across job retry clones

What does this MR do and why?

A retried job and its clone point at the same immutable, checksum-addressed job definition row, but the retry flow loaded that row four times: once on the source job (legitimate first read), once for the definition instance presence validation during the clone's save, and once each for attribute reads on the unsaved clone and on the post-reset instance (for example tag_list in the EE assignable-runners check).

This MR shares the already-loaded record instead: it is passed through the nested job_definition_instance attributes (so the presence validation uses the cached target), attached to the clone's through association for pre-save reads, and re-attached after the post-save reset (which is an eager reload that drops the association cache). Measured on the jobRetry GraphQL mutation with CI variables, this removes 2 SQL queries.

The definition row is immutable by design (content-addressed via checksum), so re-attaching the source job's instance cannot serve stale data.

Feature flag

Guarded by the ci_retry_shared_job_definition derisk feature flag (disabled by default, actor: project). When disabled, the clone assigns only the job definition id, exactly as before. Both states are covered by specs.

Dependency

Stacked on the retry association-preservation MR (see References), which this MR's target branch reflects; it will be retargeted to master when that MR merges.

References

• Depends on: !247529 (merged)
• Proof of concept: !247416
• #606207

MR acceptance checklist

Evaluated against the MR acceptance checklist.