Add sensitive-data-flow check

[scholtzan]

Description

Related to https://docs.google.com/document/d/1KhWaH-o7EDG1PaOR7JKrGWyP8hmdtodCQRino-PKbA0/edit?tab=t.0

This PR adds a CI step that flags queries that read restricted/workgroup-gated data and write it to a more broadly readable destination the source's readers don't already cover. It's advisory and non-blocking: on an ungated flow, CI flags @mozilla/dataplatform-wg in a PR comment rather than failing (#9863 (comment)).
Marking the team for review isn't currently working with the PAT.

This is a guardrail to prevent users accidentally making restricted data more widely available. I think this could be good to have as we provide write access to this to all of Mozilla. (but open to discussion/feedback)

• Source ACLs resolve from dataset_metadata.yaml
• stable/live ACLs live under sensitivity: in bqetl_project.yaml
• Exposed as ./bqetl data_governance sensitivity <paths> and CI runs it over changed query.sql files.

Reviewer, please follow this checklist

[github-actions]

⚠️ Sensitive-data flow detected — requesting @mozilla/dataplatform-wg review.

A changed query reads restricted / workgroup-gated data and writes it to a more broadly readable destination that no team owns:

- moz-fx-data-shared-prod.contextual_services_stable (gated) -> moz-fx-data-shared-prod.telemetry_derived
    grants read to workgroup:mozilla-confidential/data-viewers not authorized on the source
    needs Data Platform (@mozilla/dataplatform-wg) review

This is advisory and does not block merge.
A Data Platform reviewer should confirm the widened access is intended, or narrow the destination's workgroup_access.

[github-actions]

Adds bigquery_etl/sensitivity.py, a ./bqetl data_governance sensitivity command, a sensitivity: config block in bqetl_project.yaml describing stable/live ACLs, and a flag-sensitive-flows CI job that requests @mozilla/dataplatform-wg review and comments when a changed query.sql reads gated data and writes somewhere broader. The check is advisory (exit 2, never blocking) and the module has good unit-test coverage across access resolution, gated-dataset lookup, CODEOWNERS matching, and the CLI.

Two things stand out. First, DatasetAccess.sensitive treats an empty reader set as non-sensitive, so every gated_datasets entry written as [] — search_terms, search_terms_derived, account_ecosystem, xfocsp_error_report, client_deduplication — is silently exempt from the check. Second, the CI job reads github.event.pull_request directly, so it does nothing on the workflow_run path that fork PRs take; the workflow already has resolve-pr-base and Determine context solving exactly this. The two sensitivity_ci_probe_* query directories are marked "delete before merge" and still present.

The remaining comments are smaller: silent exception swallowing in check_query, duplicate PR comments on each push, the cost of the new ready_for_review trigger, and two minor cleanups.

[github-actions]

⚠️ Sensitive-data flow detected — cc @mozilla/dataplatform-wg, please review.

A changed query reads restricted / workgroup-gated data and writes it to a more broadly readable destination that no team owns:

- moz-fx-data-shared-prod.contextual_services_stable (gated) -> moz-fx-data-shared-prod.telemetry_derived
    grants read to workgroup:mozilla-confidential/data-viewers not authorized on the source
    needs Data Platform (@mozilla/dataplatform-wg) review

This is advisory and does not block merge.
A Data Platform reviewer should confirm the widened access is intended, or narrow the destination's workgroup_access.

[BenWu]

some non-blocking notes

[BenWu]

suggestion(non-blocking): I think this is fine for a first pass but this will likely become stale. It would be easy to parse the ingestion table permissions from the json file if it wasn't in a private repo. I think that would be better but doesn't need to be solved right now

[BenWu]

Not widely used in bigquery-etl, but roles/bigquery.dataEditor would also be a reader role. Probably doesn't change the outcome of this though

[scholtzan]

Integration report

• View full diff, if available (SQL + DAGs) (requires private-bigquery-etl access)
• Private CI run
• Bigeye monitoring dry-run: ❌ failure — view plan (requires private-bigquery-etl access)