Expose issue start dates in GraphQL

What does this MR do and why?

This is the backend half of the fix for #576912. The dashboard will consume the field in a separate frontend follow-up so the GraphQL capability can land before the frontend depends on it.

This MR exposes nullable Issue.startDate. Because EpicIssueType inherits IssueType and is backed by Work Items, it also conditionally preloads dates_source when startDate is selected. QueryRecorder coverage verifies that the inherited field does not introduce an N+1 query; ordinary Issues continue to read the loaded scalar.

The GraphQL reference and introspection artifacts were regenerated with gitlab:graphql:update_all.

Follow-up and deployment

This MR intentionally contains only the backend GraphQL support. After it merges, I will open the dashboard/frontend MR as Draft. Frontend and UX review, screenshots, and CI can proceed while that MR is Draft, but it will remain Draft until the backend field is safe to consume under the applicable deployment and version requirements. The frontend MR will close the issue; this MR does not.

Review routing

Please route this to a backend maintainer or domain reviewer and a GraphQL domain expert. The generated GraphQL reference also requires Technical Writing review routing.

References

Relates to #576912

Screenshots or screen recordings

Not applicable. This MR adds backend GraphQL capability and intentionally makes no UI change.

How to set up and validate locally

1. Create or choose an Issue with both Start Date and Due Date set.

2. Open GraphQL Explorer while signed in and run:

   query GetIssueDates($fullPath: ID!, $iid: String!) {
     project(fullPath: $fullPath) {
       issue(iid: $iid) {
         id
         startDate
         dueDate
       }
     }
   }

   Use variables matching the Issue:

   {
     "fullPath": "namespace/project",
     "iid": "1"
   }

3. Confirm that startDate and dueDate return the persisted dates.

MR acceptance checklist

This change is additive and nullable. It does not change authorization or error behavior, add a lookup for ordinary Issues, or repair the unrelated existing Epic dueDate behavior. Focused correctness and N+1 regression specs, surrounding type and resolver specs, generated GraphQL consistency checks, RuboCop, and local commit-message checks pass. Full CI and MR-side Danger remain required.