Remove FF_GITLAB_SHELL_SSH_CERTIFICATES environment variable

What does this MR do and why?

Related to gitlab#633203

Removes the FF_GITLAB_SHELL_SSH_CERTIFICATES environment variable from gitlab-sshd.

The variable was added in 2023 (f3c80161, !812 (merged)) as a rollout switch for group SSH certificates on GitLab.com. Today it only controls whether gitlab-sshd asks Rails (GET /internal/authorized_certs) about a certificate whose signing CA is not in sshd.trusted_user_ca_keys. Locally trusted CAs and normal SSH keys are unaffected.

Rails already decides whether each scope is available, so the extra switch adds no protection:

Scope	Rails check	Where it can succeed
Group	ssh_certificates licensed feature, group membership, and user.enterprise_user_of_group?(group). Enterprise users require domain_verification_available?, which requires Gitlab.com?.	GitLab.com only
Instance (database)	InstanceSshCertificate.available? = !Gitlab.com? && Feature.enabled?(:instance_ssh_certificates, :instance), checked on every lookup	Self-managed / Dedicated, only with the beta flag enabled
CE	group_ssh_certificate_response always returns CERTIFICATE_NOT_FOUND	Instance scope only, as above

The variable is now mainly an obstacle for the instance_ssh_certificates beta. The docs list it as a prerequisite for CAs added in the Admin area, but give no way to set it in Omnibus or Helm.

Behaviour changes

• GitLab.com. No change.
• Logs. Rejections for certificates from CAs that aren't locally trusted no longer log handleUserCertificate: feature is disabled. They return the Rails 403/404 error instead.
• API calls. Certificates signed by an unknown CA now trigger an /authorized_certs request instead of being rejected locally. This is the same kind of cost as the existing /authorized_keys lookup for any offered public key.