Add GitLab webhook support

[jgsuess]

Add GitLab webhook support

Closes #19

Summary

This PR adds GitLab push webhook support to the IG auto-builder, enabling public GitLab repositories (gitlab.com and self-hosted instances) to trigger builds and publish to build.fhir.org/ig/.

The experience mirrors GitHub's manual webhook era: add a webhook URL to your GitLab project settings, and builds trigger on push. The architecture is designed to support a future GitLab Integration/OAuth App for one-click setup (analogous to the existing GitHub App).

What changes

Trigger function (triggers/ig-commit-trigger/):

• New platform.js module detects GitLab via X-Gitlab-Event header and normalises payloads into a BuildRequest struct
• hasIgIni and resolveHead dispatch to GitLab's raw file URL / Commits API for GitLab repos
• Non-push GitLab events (tag push, merge request, etc.) are rejected with an informative message
• scheduling.js threads cloneUrl and platformUrl to the K8s Job as IG_CLONE_URL and IG_PLATFORM_URL env vars
• A build.fhir.org/platform annotation is added to jobs for observability

Builder image (images/ig-publisher/):

• builder.py uses IG_CLONE_URL if set (falls back to existing GitHub URL construction)
• Notification messages use IG_PLATFORM_URL for source links

Publish script (images/ci-build/publish-ig):

• Fixed temp directory name to handle slashes in IG_ORG (GitLab orgs are prefixed with hostname)

Output namespacing:

• GitLab builds publish to build.fhir.org/ig/gitlab.com/:namespace/:project/branches/:branch
• Avoids collisions with GitHub org/repo names
• mkdir -p and relative symlinks handle the nested paths correctly

Design decisions

1. Platform prefix in IG_ORG (gitlab.com/namespace) rather than a separate path variable — minimises changes to publish-ig and watch-and-publish which already handle IG_ORG/IG_REPO paths
2. BuildRequest normalisation boundary — adding other forges (Gitea, Bitbucket) later only requires a new parser in platform.js
3. Base URL derived from webhook payload — supports self-hosted GitLab instances without configuration
4. No new dependencies — uses standard fetch against GitLab's public API

Backward compatibility

• All existing GitHub behaviour is unchanged (same code path when no X-Gitlab-Event header)
• Legacy curl triggers without any platform header continue to work as GitHub
• IG_CLONE_URL/IG_PLATFORM_URL are optional — jobs without them behave exactly as before
• All existing tests pass unmodified

Testing

$ npm test
=== Branch-Head Scheduling Tests ===
[16 tests] All tests passed.
Sweep tests passed.
=== GitLab Webhook Parsing Tests ===
[11 tests] All GitLab tests passed.

$ npm run typecheck
tsc --noEmit  (clean)

New tests cover:

• Simple namespace (user/project)
• Nested groups (org/subgroup/project, a/b/c/project)
• Self-hosted GitLab instance URL derivation
• Non-push event rejection (tag_push)
• Missing/malformed payloads
• GitHub backward compatibility
• Env var injection into K8s Jobs (IG_CLONE_URL, IG_PLATFORM_URL, platform annotation)
• GitHub jobs do NOT receive GitLab-specific env vars

Not yet tested (need infrastructure)

• Live build from a real public GitLab repo (needs cluster access)
• Builder Docker image clone via IG_CLONE_URL (needs image rebuild)
• End-to-end publish path verification in minikube

GitLab setup instructions (for users)

1. Go to your GitLab project → Settings → Webhooks → Add new webhook
2. URL: https://us-central1-fhir-org-starter-project.cloudfunctions.net/ig-commit-trigger
3. Trigger: Push events only
4. Click Add webhook

Output appears at: https://build.fhir.org/ig/gitlab.com/:namespace/:project/branches/:branch