Cleanup orphaned renewal applications (DRAFT / PAYMENT_DUE)

## Related links

- **Investigation (SharePoint):** https://bcgov.sharepoint.com/:fl:/g/contentstorage/CSP_7b69bd6c-4492-4bc2-9954-8c3d2283d78e/IQAmzCSZBsP_RoPxwFYcQ14qAS_Y4hFqo_LjWHk6lZg-fw4
- **Related ticket:** https://github.com/bcgov/STRR/issues/1205

## Problem statement

The STRR production database currently contains **35 orphaned renewal application rows** (32 `DRAFT`, 3 `PAYMENT_DUE`) across **16 registrations**. These orphaned rows are the result of missing server-side duplicate guards and front-end draft lifecycle issues, as detailed in the investigation report. They clutter examiner and user dashboards, causing confusion and potentially impacting workflow and reporting.

## Proposed solution

1. **Cancel or soft-delete** all orphaned renewal applications (status `DRAFT` or `PAYMENT_DUE`) that have never reached payment or submission. Soft delete could mean setting a new status perhaps (e.g.: `ARCHIVED`).
2. **Update examiner and user dashboards** to exclude these orphaned rows from active views (where still applicable after data cleanup).

## Acceptance criteria

- [ ] All orphaned `DRAFT` and `PAYMENT_DUE` renewal rows are either cancelled or soft-deleted (per product/data retention policy).
- [ ] Dashboards and reporting tools reflect only legitimate renewal applications.
- [ ] No legitimate paid or processed renewals are affected by the cleanup.

## Additional context

See the investigation report for detailed breakdowns and timing patterns.

**Appendix — SQL used to identify affected rows (example; validate against current schema):**

```sql
SELECT *
FROM application
WHERE registration_id IN (
SELECT registration_id
FROM application
WHERE type = 'renewal'
AND registration_id IS NOT NULL
GROUP BY registration_id
HAVING COUNT(*) > 2
)
AND status IN ('DRAFT', 'PAYMENT_DUE');
```

Start with the example SQL query and the related issue #1205, then review the investigation report for how orphaned rows are identified. Trace the examiner and user dashboard queries that include DRAFT or PAYMENT_DUE renewals. Done means cleanup follows the product/data-retention decision, dashboards show only legitimate renewals, and paid or processed renewals remain unaffected.

Written by the indexing model from the issue text.