chore(DENG-11021): cancel cohort_daily_churn_v1 and cohort_weekly_cfs_staging_v1 tier 2 backfills

[kbammarito]

Description

Cancels the four Tier 2 cohort_daily_churn_v1 / cohort_weekly_cfs_staging_v1 install_source backfills initiated in #9690, to be redone as single-date backfills:

• telemetry_derived.cohort_daily_churn_v1
• glean_telemetry_derived.cohort_daily_churn_v1
• telemetry_derived.cohort_weekly_cfs_staging_v1
• glean_telemetry_derived.cohort_weekly_cfs_staging_v1

All four set scheduling.date_partition_parameter: null, which tells the backfill machinery to WRITE_TRUNCATE the whole table each run rather than write a single partition. Each run then rebuilds a trailing rolling window off @submission_date (churn 180 days, cfs_staging 768 days) — so the initiated 2025-01-01 -> 2026-07-06 range just re-truncates each table ~550 times and only the last run survives. They'll be re-initiated single-date (start_date == end_date) so one run rebuilds the full window.

Related Tickets & Documents

• DENG-11021
• DENG-11362

Reviewer, please follow this checklist

[github-actions]

This PR flips the status field from Initiate to Cancelled in four backfill.yaml files (cohort_daily_churn_v1 and cohort_weekly_cfs_staging_v1 under both telemetry_derived and glean_telemetry_derived), cancelling the Tier 2 install_source backfills started in #9690 so they can be re-run as single-date backfills.

Cancelled is a valid backfill status (bigquery_etl/backfill/parse.py), each file contains a single entry so there's no duplicate-Initiate concern, and the four edits are consistent. The rationale is well explained in the PR description. I found no code-quality or correctness issues to raise.

[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)