Expose environment on CiJob in GraphQL

What does this MR do and why?

This MR adds an expandedEnvironmentName field to the CiJob GraphQL type. The value comes from the job_environments table, which GitLab populates with the already variable-expanded environment name when the pipeline is created. The field only reads that recorded value; it does not re-expand variables at query time.

Current variable values can differ from the ones in effect when the pipeline was created, so expanding now could return a name the job never actually ran against. The field is authorized against :read_environment, so it respects the environment feature's access level. It returns null when the job does not declare an environment, when no name was recorded for it, or when the user cannot read environments.

Changelog: added

References

Relates to #607099 (closed)

How to set up and validate locally

1. In GDK, create a new project (or use an existing one) and make it public, a later authorization step needs a non-member to read the project's jobs.

2. Go to CI/CD > Pipeline editor and commit this configuration to the default branch:

   stages:
     - deploy
   
   deploy-static:
     stage: deploy
     script: echo ok
     environment: production
   
   deploy-dynamic:
     stage: deploy
     script: echo ok
     environment: review/$CI_COMMIT_REF_SLUG
   
   no-environment:
     stage: deploy
     script: echo ok

3. Go to CI/CD > Pipelines and confirm a pipeline exists for the commit. If none appeared, select Run pipeline and run it against the default branch. No runner is needed, the jobs can sit in created/pending forever and the field still returns values, since the environment records are written at pipeline creation.

4. Optionally confirm at Deployments > Environments that production and review/<default-branch-slug> now exist.

5. Open /-/graphql-explorer and run this query, substituting the project's full path:

   {
     project(fullPath: "<group>/<project>") {
       pipelines(first: 1) {
         nodes {
           jobs {
             nodes {
               name
               expandedEnvironmentName
             }
           }
         }
       }
     }
   }

6. Confirm the response: deploy-static returns "production"; deploy-dynamic returns the expanded branch slug, for example "review/main" on a main branch; no-environment returns null.

7. Verify authorization. Go to Settings > General, expand Visibility, project features, permissions, and set the Environments row to Only Project Members. Save.

8. Re-run the same query in a private/incognito window, so you are signed out and a non-member. Every expandedEnvironmentName comes back null while name still returns normally. The check is per-user, not per-job, so all jobs go null together. Re-running it as a project member while the restriction is still in place should still return the names.

9. Set Environments back to Everyone With Access and re-run the query as a project member to confirm the values return.

10. Verify the external commit status case. External commit statuses also surface through the CiJob type but have no environment support, so they must return null rather than error. Get the commit SHA from the project's Commits page and a token from User settings > Access tokens:

    curl --request POST --header "PRIVATE-TOKEN: <your-token>" \
      "http://127.0.0.1:3000/api/v4/projects/<project-id>/statuses/<commit-sha>?state=success&name=external"

    Then re-run the GraphQL query. A job named external appears with expandedEnvironmentName of null, and the response contains no errors key.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #607099 (closed)