Add URL masking, custom headers, and custom template to system hooks

What does this MR do and why?

Add URL masking, custom headers, and custom template to system hooks

System hooks were missing features already available to project and group webhooks: URL masking (url_variables), custom request headers, and custom webhook templates. All three are now supported at parity.

• Permit custom_webhook_template in the admin hooks controller and API
• Replace the admin-only HAML form with the shared Vue webhook form, deleting app/views/admin/hooks/_form.html.haml
• Move hook-type-specific sections in shared/_form.html.haml behind hook.is_a? guards (ProjectHook for deploy token events, SystemHook for the member_approval_events EE partial and docs link)
• Add repositoryUpdateEvents to WebhookFormTriggerList rendered before PushEvents to preserve the original trigger order
• Filter TRIGGER_CONFIG by initialTriggers keys so system hooks only show their four applicable triggers
• Pass isSystemHook as an explicit prop through the Vue component tree (helper → index.js → WebhookFormApp → WebhookFormTriggerList)
• Expand system hooks documentation with sections for configurable triggers, URL masking, custom headers, and custom webhook template

References

#503457

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Verify the new system hook form

1. Go to Admin area → System hooks (/admin/hooks).
2. Select Add new webhook.
3. Confirm the form now shows: Name, Description, URL field with URL masking support, Secret token, Custom headers, Trigger checkboxes, Custom webhook template,
   and SSL verification.

2. Verify URL masking

1. In URL, enter https://webhook.example.com/hook?token={token}.
2. Select Add URL masking.
3. In Sensitive portion of URL enter token (variable name).
4. In How it looks in the UI enter *** (masked value).
5. Select Save changes - no error should appear.
6. Re-open the hook - confirm the URL variable is preserved and the URL field shows the masking UI.

3. Verify custom headers

1. On the same hook, expand Custom headers and add a header (for example, X-Custom-Header: secret).
2. Save and re-open - confirm the header key is shown (value is masked).

4. Verify custom webhook template

1. In Custom webhook template, enter {"event": "test"}.
2. Save and re-open - confirm the template is preserved.

5. Verify trigger checkboxes (system-hook-specific)

Confirm only the four applicable triggers are shown - no project/group-only triggers
(for example, no Comments, Work items, or Pipelines):

• Repository update events
• Push events (with branch filter options when enabled)
• Tag push events
• Merge request events

6. Verify REST API

# Create a system hook with a custom template and custom header
curl --location 'https://gdk.test:3000/api/v4/hooks' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer ACCESS_TOKEN' \
--data '{
    "url": "https://webhook.example.com/hook?token=token",
    "url_variables": [
        {
            "key": "token",
            "value": "secret"
        }
    ],
    "custom_headers": [
        {
            "key": "X-My-Header",
            "value": "value"
        }
    ],
    "custom_webhook_template": "{\"event\": \"test\"}"
}'                                                                                                               
                                                          
# Fetch the hook - confirm fields are returned  
                                                                                                            
curl --location 'http://gdk.test:3000/api/v4/hooks/14' \
--header 'Authorization: Bearer ACCESS_TOKEN'                                                                                                     

7. Regression check - project webhooks

8. Go to a project's Settings → Webhooks.

9. Confirm the form still shows all project triggers (Comments, Work items, Pipelines, etc.) - the trigger filtering must not affect project hooks.

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.