docs: rename "Data Retention" check to "Storage Proving" check

[silent-cipher]

Part of #649

[Copilot]

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

[beck-8]

One spot seems to have been missed: docs/checks/README.md still shows the old display name in two places, which is now inconsistent with the renamed data-retention.md:

- [data-retention.md](./data-retention.md): Defines the "data retention check" and how it is calculated.

### Check
A "check" refers to a task type that dealbot performs on an SP. We currently have [Data Storage](./data-storage.md), [Retrieval](./retrievals.md), [Data Retention](./data-retention.md), [Sampled Retrieval](./sampled-retrievals.md), and [Pull](./pull-check.md) checks.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

docs/data-set-creation.md:18

• Blocker: This doc still uses the old “data-retention” naming in the Summary and uses a lowercase “storage proving check” later, which conflicts with the PR’s rename to “Storage Proving”. This makes the doc internally inconsistent and undermines the rename effort.

Suggested: update the Summary bullet and the paragraph in “Why it was added…” to refer to the Storage Proving check consistently (while keeping the internal identifier data_retention as code formatting).

This job was originally added so dealbot could maintain enough datasets per provider for `data_retention` to accumulate enough samples to evaluate FWSS approval criteria. In practice, raising `MIN_NUM_DATASETS_FOR_CHECKS` increases the number of datasets per provider, which increases on-chain proof samples for storage proving check.

docs/provider-scoring.md:54

• Blocker: provider-scoring.md renames the weight-table row to “Storage Proving”, but the rest of the document still uses the old “Retention” terminology (e.g., “retention periods” and multiple scenario bullets labelled “Retention: …”). This leaves the doc inconsistent and partially updated relative to the PR goal.

Suggested: update the remaining narrative and scenario labels to “Storage Proving” (and consider “proving periods/challenges” where appropriate) so the terminology matches throughout.

| Storage Proving | 40 % | Data loss is the worst outcome for a storage service; ongoing proof-of-custody is hard to fake and has no client-side recovery path |