QVAC-18608 infra: add qvac-collabora to label-gate trusted defaults

[Proletter]

🎯 What problem does this PR solve?

• PRs authored from Collabora forks (e.g. #2088 by @zoq) lose their verified authorisation on every synchronize event, even after a Tether engineer reviews and labels them. CI silently stops running until somebody re-applies the label by hand, which is currently blocking Collabora's iteration loop and was raised as a blocker in Slack.
• Root cause: qvac-collabora is not in label-gate's default trusted teams input. The action's synchronize policy denies (and tries to strip) the label on any push from a non-trusted actor — by design, to prevent authorisation inheriting across content changes from an untrusted contributor. That policy is correct, but it should treat Collabora as trusted.

📝 How does it solve it?

• Adds qvac-collabora to the default teams input of .github/actions/label-gate/action.yml. This is Collabora's broad contributor team, and every Collabora engineer shipping against this repo is in it, so a single entry is sufficient to unblock the synchronize path.
• Does not add a -merge companion tier. The Tether-side merge / release gates (qvac-internal-merge, qvac-internal-release) continue to govern the merge flow; label-gate only governs CI authorisation, and "trusted enough to keep CI running on your own PRs" is the right semantic for the broader qvac-collabora membership.
• Action policy logic is unchanged. Only the default trusted-team list grows; per-workflow callers that override teams: are unaffected.
• Mirrors the doc surface (docs/ci/TEAMS.md, docs/ci/LABELS.md, label-gate/README.md) and the devops-why-my-pr-not diagnostic skill so the trusted set is discoverable from anywhere a developer might look.

🧪 How was it tested?

• node --test .github/actions/label-gate/test/*.test.mjs → 58 / 58 pass. The test fixtures hard-code their own TEAMS constant rather than reading the action default, so policy coverage is unaffected by the addition.

• Verified the YAML is valid and the new default parses to the expected 4-entry list.

• Confirmed qvac-collabora exists in the tetherto org and that @zoq (PR [DRAFT] QVAC b8828 #2088 author) is state=active:

  gh api orgs/tetherto/teams/qvac-collabora/memberships/zoq
  # {"state":"active","role":"member",...}

  So after this PR merges, synchronize events from him on a labelled PR will be considered trusted and the gate will keep the label in place.

• No workflow files touched, so actionlint over .github/workflows/** is unchanged. actionlint does not consume composite-action manifests under .github/actions/**/action.yml.

🔗 Context

• Original label-gate implementation: QVAC-18608 (PRs QVAC-18608 infra: add .github/actions/label-gate (Node 20) #1968, QVAC-18608 fix(label-gate): preserve hyphens in input env-var names #1973, QVAC-18608 fix(label-gate): strip label when non-trusted user applies it #1978, QVAC-18608 fix: trust repository_dispatch events in label-gate #1995).
• Triggering thread: PR tetherto/qvac#2088. Timeline shows synchronize events from @zoq on May 18 (11:53, 12:05, 21:34, 22:06 UTC) each causing the gate to deny — confirming the diagnosis.

🐛 Known follow-up — strip 403

While debugging this issue I also observed that the action's strip call returned HTTP 403 (DELETE /repos/tetherto/qvac/issues/2088/labels/verified) on PR #2088's untrusted synchronize events. Per the action's exit policy, an unhandled API error is treated as hard misconfiguration → the gate job goes red rather than silently denying. That is a separate issue from this PR (it's about the PAT_TOKEN not having sufficient permission to delete a label on a base-repo PR triggered from a fork) and would still bite us for any genuinely untrusted contributor.

After this PR lands, Collabora pushes will no longer trip the strip path (zoq is now trusted), but the latent PAT-permission issue remains. I'll open a follow-up to triage the PAT_TOKEN scope and ensure DELETE /repos/.../issues/{n}/labels/{name} succeeds, so we don't continue to fail loudly on legitimately-untrusted PRs. Required scopes that need to be granted on the PAT (or a replacement GitHub App installation token):

• Classic PAT: repo + read:org, SSO-authorised for tetherto.
• Fine-grained PAT (resource owner tetherto, repo tetherto/qvac): Issues: Write, Pull requests: Write, Contents: Read, Metadata: Read, and org-level Members: Read.

[github-actions]

Tier-based Approval Status

**PR Tier:** TIER1

**Current Status:** ✅ APPROVED

**Requirements:**
- 1 Team Member approval ❌ (0/1)
- 1 Team Lead OR Management approval ✅ (2/1)

**Bypass rule:** Triggered (2+ Team Lead approvals (Tier 1 exception)). This PR is approved regardless of tier.

---
*This comment is automatically updated when reviews change.*

[Proletter]

/review