Derive the Pages artifacts server from gitlab_server again

What does this MR do?

Since 19.2.0 (!9547 (merged)), gitlab_pages['artifacts_server_url'] defaulted to internal_gitlab_server when that was set. The Pages troubleshooting docs tell administrators behind a TLS-terminating load balancer to point internal_gitlab_server straight at Puma (http://localhost:8080), and for them the Pages daemon then requested artifact files from Puma directly. Artifact file responses are completed by Workhorse's senddata mechanism, which Puma alone cannot do, so every artifact browsed through the Pages domain returned 403 (or an empty 200 on 19.2.0) while regular Pages sites kept working.

This MR derives the default from gitlab_server again, which is what gitlab.rb.template still documents ("Defaults to external_url + '/api/v4'"), and pins that in the spec alongside the internal_gitlab_server rendering. An explicit artifacts_server_url still wins, so anyone who needs the internal target can set it.

Related issues

Closes #10086

Checklist

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• Tests added or updated
• Documentation updated (the template comment already describes this behaviour)
• Changelog trailer added