ci: dispatch coverage-fanout on merged source PRs

[eric-wang-1990]

Summary

Wires databricks-sql-python into the multi-language coverage fan-out in databricks/databricks-driver-test. When a PR merges to main and touched driver source (a file under src/), dispatch a coverage-fanout repository_dispatch to driver-test; its coverage-fanout-tracker.yml opens a tracking issue and runs the language-agnostic fan-out — a spec authored from this PR's diff, conformed as tests across every driver (csharp/python/go/nodejs/rust/kernel/jdbc).

Same sender adbc-drivers/databricks already runs; this is one of a set of sibling PRs bringing the remaining driver repos onto the flow.

What it does

• Adds closed to the pull_request trigger types; the new trigger-coverage-fanout job gates on github.event.pull_request.merged == true.
• Source-path filter (src/): docs/CI/test-only merges don't kick off a full 7-leg fan-out.
• Reuses the existing INTEGRATION_TEST_APP_ID/_PRIVATE_KEY App token (scoped to driver-test) + the same peter-evans/repository-dispatch pin adbc uses.
• Tightens skip-integration-tests-pr's guard to exclude closed so it doesn't re-stamp a check on merged PRs.

Test Plan

• YAML validates; job-guard audit confirms no existing job misfires on the new closed event.
• After merge: a subsequent merged source PR shows a coverage-fanout dispatch + a new tracking issue in databricks/databricks-driver-test.

This pull request and its description were written by Isaac.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[peco-review-bot]

Verdict: 1 Low

Looks good — a well-scoped CI addition that mirrors the existing dispatch pattern. One low-severity note: the new trigger-coverage-fanout job omits an explicit permissions: block that every sibling job in this file declares, so its pulls.listFiles call relies on the org's default GITHUB_TOKEN permissions. The closed-event guards and skip-integration-tests-pr exclusion are correct, and the client-payload has no injection surface (no PR-title interpolation).

[peco-review-bot]

Verdict: 1 Medium

Looks good overall — the closed event is added cleanly and all existing jobs have explicit event/action guards, so none misfire on it (and skip-integration-tests-pr correctly excludes closed). One medium concern: the new trigger-coverage-fanout job has no base-branch guard, so it fires for merges into any branch, not just main as the description intends.

[peco-review-bot]

✅ No issues identified by the review bot.

[peco-review-bot]

Verdict: 1 Low

Looks good — the new trigger-coverage-fanout job is well-gated (merged + base.ref==main + src/ path filter), the skip-integration-tests-pr guard is correctly tightened to exclude closed, and I audited every other job's if (synchronize / labeled / merge_group) to confirm none misfires on the new closed event. One low note on the failure-handler's comment wording. Nit: this job declares pull-requests: write but not issues: write, whereas the sibling comment-posting jobs declare both; issues.createComment on a PR works with pull-requests: write and the call is wrapped in try/catch, so this is non-fatal, but the permission set is inconsistent with the rest of the file.

[peco-review-bot]

Verdict: 1 Low

Looks good — the closed-event guard audit checks out: every pre-existing job correctly ignores closed (synchronize/labeled/merge_group), skip-integration-tests-pr now excludes it as intended, and the new trigger-coverage-fanout job is properly gated on merged == true + base.ref == 'main'. Payload interpolations are injection-safe and the failure-handler gate reasoning is sound. One low-severity note about duplicate dispatch on manual re-runs.

[peco-review-bot]

Verdict: 1 Medium

Looks solid — the closed event is correctly fenced off from every pre-existing job, and the new trigger-coverage-fanout job's gating/failure-handler reasoning is sound. One medium concern: for merged fork PRs, pull_request events don't carry secrets, so the fan-out (and its failure comment) can silently no-op.

[peco-review-bot]

Verdict: 1 Medium

Looks solid overall — the closed-event wiring is well-guarded (every other job correctly excludes the new event) and the failure-handler/truncation reasoning is sound. One medium concern: fork src merges aren't cleanly excluded at the job level, so they produce a red workflow run rather than the silent exclusion the header comment claims.

[peco-review-bot]

Verdict: 1 Low

Looks good — a carefully-scoped CI change with thorough gating and inline rationale. I verified the whole workflow: on the new closed/merged event no existing job misfires (remove-label-on-new-commit gates on synchronize, skip-integration-tests-pr now excludes closed, trigger-tests-pr on labeled, merge-queue-python on merge_group), and the new trigger-coverage-fanout job correctly requires merged==true + base main + non-fork, serializes via concurrency, and fails safe on the source-detection path. One low-severity permissions observation noted inline.

[peco-review-bot]

✅ No issues identified by the review bot.