Create API endpoint to refresh validity status of finding

What does this MR do and why?

Issue: #537133 (closed)

Create API endpoint to refresh validity status of a single finding

How to set up and validate locally

1. In gdk, ensure you have an Ultimate license
2. In rails c, Feature.enable(:validity_checks) and Feature.enable(:secret_detection_validity_checks) -- we're about to globally enable validity_checks for a different portion of the feature, so this MR had to introduce a new secret_detection_validity_checks FF to limit API calls for now.
3. In Project > Secure > Security configuration, enable Pipeline Secret Detection. Ensure that the secret_detection job passes. You may have to set up your runner to use docker, instructions here: https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/runner.md#executing-a-runner-from-within-docker
4. In Project > Secure > Security configuration > Validity Checks, toggle the Validity Checks feature to true (or in rails c, project.security_setting.update!(validity_checks_enabled: true)
5. Create a personal access token and copy the value to your clipboard
6. In your project, create a file secrets.txt and paste your personal access token into it. Commit the file, skipping secret push protection if needed.
7. In Project > Secure > Vulnerability report, go to your latest vulnerability (the description should say "GitLab personal access token")
8. The Validity Check value should be "Active secret", which is correct because you just committed an active personal access token
9. In gdk.test:3000/-/graphql-explorer, run the following mutation:

mutation {
  refreshFindingTokenStatus(
    input: { vulnerabilityId: "gid://gitlab/Vulnerability/<vulnerability_id>" }
  ) {
    errors
    findingTokenStatus {
      id
      status
      createdAt
      updatedAt
    }
  }
}

You should see something like:

{
  "data": {
    "refreshFindingTokenStatus": {
      "errors": [],
      "findingTokenStatus": {
        "id": "gid://gitlab/Vulnerabilities::FindingTokenStatus/585",
        "status": "ACTIVE",
        "createdAt": "2025-06-24T20:03:30Z",
        "updatedAt": "2025-06-24T20:03:30Z"
      }
    }
  },
  "correlationId": "01JYQ8HCSFDKZ9MW8BVY90CMCX"
}

11. Note that it says "status": "ACTIVE"
12. In the personal access token section again, revoke the token
13. Refresh the Vulnerability finding page. The badge should still say "Active secret" since we haven't refreshed the status yet
14. In graphql explorer, run the mutation from step 9 again. Note that it now says "status": "INACTIVE", and updatedAt value should be some time after the createdAt value
15. Refresh the Vulnerability finding page again, the badge should now say "Inactive secret" since the status has been refreshed and the new status has been saved.

Bonus:

1. Impersonate a non-member of the project. Attempt to run the mutation again, you should get "message": "The resource that you are attempting to access does not exist or you don't have permission to perform this action".
2. Change the input vulnerabilityId to a non-existent vulnerability, you should get the same message as above.
3. Disable validity checks, you should get "errors": ["Validity checks is not enabled for gitlab-org/gitlab-test"]

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.