infra[notask]: add qvac-ci pending-approval workflow and update CODEOWNERS

[sidj-thr]

🎯 What problem does this PR solve?

• The initial commit on this branch used the legacy team name ai-runtime-merge-mgmt in both CODEOWNERS and the --maintainers-team flag. The management team has been renamed to qvac-internal-mgmt per the GitHub org restructuring (github-ops PR #182).
• The workflow, job id, and step names (Count Pending Approvals / count-reviews) did not match the Check Approvals / check-approvals naming convention required for branch protection status checks.

📝 How does it solve it?

• Updates .github/CODEOWNERS: replaces @tetherto/ai-runtime-merge-mgmt with @tetherto/qvac-internal-mgmt.
• Updates .github/workflows/check-pending-approval.yml: renames workflow name, job id (count-reviews → check-approvals), job display name, and step name to Check Approvals; updates --maintainers-team flag to qvac-internal-mgmt.

🧪 How was it tested?

Validated on tetherto/qvac-internal against a 3-case matrix before rollout:

• Test 1 — 2 team-lead approvals (PR #27, run 27414621255): 2 members of qvac-internal-merge approved → workflow passed, PR mergeable. ✅
• Test 2 — 1 team-lead + 1 team-member approval (PR #28, run 27420573302): 1 qvac-internal-merge + 1 qvac-internal-dev approved → workflow passed, PR mergeable (code-owner approval satisfied). ✅
• Test 3 — 2 team-member approvals only (PR #29, run 27420584636): 2 qvac-internal-dev members approved → workflow reported pending, PR blocked by CODEOWNERS ruleset (no code-owner approval). ✅ (expected failure)

🛡️ Permissions changes

• Scope: top-level
• Before: contents: read, pull-requests: write, issues: write (set in the initial commit on this branch)
• After: unchanged — contents: read, pull-requests: write, issues: write
• Justification: permissions block is not modified; listed for completeness as the workflow file is being updated in this fixup commit.

---

Ruleset note: This repo's branch ruleset requires 2 approvals on main. --min-approvals '2' is set accordingly. The Check Approvals status check is informational (continue-on-error: true); enforcement is via native GitHub code-owner rules in the ruleset.