Improvements to CI check flagging sensitive data flows

[scholtzan]

Description

Fixes the "Flag sensitive data flows" check failing the build when it had nothing to report . The step now always exits 0.

Also retracts stale advisories: when a push clears the flow, the check deletes its earlier comment and withdraws its own dataplatform-wg review request.

Related Tickets & Documents

• Follow-up to Add sensitive-data-flow check #9863
• Example failure: https://github.com/mozilla/bigquery-etl/actions/runs/35161047700/job/105011703128?pr=9828

Reviewer, please follow this checklist

[github-actions]

This changes the Flag sensitive data flows step in .github/workflows/build.yml so it no longer propagates the sensitivity CLI's exit code, moves the any_changed check from a step-level if into the script, paginates the marker-comment lookup, writes findings to $GITHUB_STEP_SUMMARY, adds a retraction path that deletes the advisory comment and withdraws the dataplatform-wg review request when a push clears the flow, and adds an explanation of unresolved sources to the comment body.

Comments are workflow-only, so nothing here touches SQL conventions or schemas from the reviewer checklist. My findings center on the new retraction path: how it interacts with CODEOWNERS-driven review requests, and the job-level gate that prevents it from running in the revert case it's meant to handle. Verified against CODEOWNERS, the decide-runs job's validate-sql computation, and bigquery_etl/data_governance/cli.py (SENSITIVITY_UNGATED_EXIT_CODE = 2).

[scholtzan]

Integration report

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