Batch dataclip retention wiping so it stops timing out on large backlogs

[stuartc]

Description

This PR fixes the data_retention Oban job timing out when a project has a large backlog of dataclips to wipe.

wipe_dataclips_for/1 was a single unbatched UPDATE ... WHERE project_id = ? AND inserted_at < ?, which reliably hits Ecto's 15s query timeout once the eligible set gets large enough (confirmed on staging via Postgrex.Error: query_canceled, after enabling retention on some old QA/test projects that had none set and had accumulated ~1TB of dataclips). Production doesn't have this today, but any customer with tens of thousands of eligible dataclips, or who pulls their retention period back, would hit the same wall.

The fix pages through eligible dataclip ids (ordered by inserted_at, matching a new partial index) and applies the wipe in activity_cleanup_chunk_size-sized batches, so no single query does more work than a normal batch job.

Closes CON-158

Validation steps

1. Seed a project with a large number of dataclips (more than a few activity_cleanup_chunk_size batches) with inserted_at older than the retention period.
2. Set dataclip_retention_period on the project and trigger the retention worker (or call Lightning.Projects.wipe_dataclips_for/1 directly).
3. Confirm it completes without hitting the Ecto query timeout, and that the same rows get wiped as before (see test/lightning/projects_test.exs for the new coverage).
4. Run the migration and confirm dataclips_pending_wipe_idx is created; re-running it after a killed CONCURRENTLY build should self-heal rather than error.

Additional notes for the reviewer

1. The migration adds a partial index shaped to match the new query (project_id, inserted_at, filtered on the wipeable types/name/wiped_at conditions) so the id-fetch stays index-backed instead of falling back to a scan.
2. fetch_size (id page size) is deliberately much larger than batch_size (update chunk size) - wiping only sets a column rather than deleting the row, so a small per-update batch would re-walk a growing prefix of already-wiped rows on every iteration.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Security Review ✅

• S0 (project scoping): New eligible_query in lib/lightning/projects.ex:1685 filters d.project_id == ^project.id; per-chunk update on d.id in ^chunk inherits that scoping since the IDs come from that project-filtered fetch.
• S1 (authorization): N/A — no new web-layer actions; changes live inside the data_retention Oban worker.
• S2 (audit trail): N/A — no configuration writes; retention wiping is an automated cleanup that already had no audit entry and this PR only changes batching.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.7%. Comparing base (1342c17) to head (0ddfc41).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #5115   +/-   ##
=====================================
  Coverage   90.7%   90.7%           
=====================================
  Files        417     417           
  Lines      20296   20305    +9     
=====================================
+ Hits       18400   18413   +13     
+ Misses      1896    1892    -4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.