MHR ToD| add document Checklist to Filing

### Background:
A structured document‑upload experience is required for Transfer‑to‑Death submissions by Qualified Suppliers. A checklist must guide filers on what to provide. An explicit attestation must record the filer’s confirmation that required documents match estate evidence. Declared value at death must be entered using the value shown on the probate assets and liabilities statement. System validation of file contents is out of scope. Staff review remains the control.
### Change Requested:
Uploads step: Present a dynamic checklist keyed to the selected ToD path. Required items must be shown in plain language. Examples include death certificate, will, estate authority evidence, assets and liabilities statement, and the bill of sale when sale is selected in the beneficiary transfer. Responsibility for correctness is anchored by attestation.
Attestation: Add a mandatory checkbox. Store user, timestamp, and acceptance text with the filing. Block progression until attestation is given.
Declared value guidance: Display persistent guidance that the declared value at death must match the probate assets and liabilities statement. Apply this to all probate‑related paths
Staff review: Leave content verification to staff. Reasons for rejection must be captured in a free‑text field and merged into both the email and PDF.
Legislative alignment: Reference to registrar proof authority, transmission on death, and verification statement requirements must be retained in help content and internal guidance.

### Business Rules
1. Type‑aware checklist: A dynamic checklist should be rendered on the uploads step, keyed to the selected Transfer‑to‑Death path (executor/administrator transmission and beneficiary transfer). Required items should be listed in plain language.
2. Mandatory attestation: An attestation control should be presented to the filer. Progression from the uploads step should require acknowledgment that all listed items have been uploaded and are complete and correct to the filer’s knowledge. The attestation decision, user ID, and timestamp should be recorded with the filing.
3. Declared value guidance: Helper text should direct that the declared value at death must equal the value stated in the probate assets and liabilities exhibit. The guidance should display for all probate‑related ToD paths. ,
4. No content interpretation by system: The system should not interpret or OCR the content of uploads. File presence, filename, type, size, and upload metadata should be recorded. Suitability and completeness should be determined by staff during review.
5. Read‑only land‑ownership indicator at transmission: During the executor/administrator transmission step, the land‑ownership indicator should be displayed as read‑only with explanatory help text clarifying that the value does not change at this stage.
6. Staff rejection reason capture: A free‑text reason should be required for any rejection. The reason should be merged into the client email and the rejection PDF.
7. Records handling for MVP: The rejection PDF should be saved to the records repository by staff as correspondence for MVP. Automation may be considered post‑MVP.
8. Legislative alignment (internal help and labels): Internal help and UI labels should reflect that transfer includes transmission, that proof may be required by the registrar, and that a verification statement is issued upon approval, consistent with the Regulation.
9. Contact details in templates: Client communications should reference the correct BC Registries contact information rather than legacy help channels.
10. Package completeness before submission: Submission of the ToD package for staff review should require that both steps (transmission and beneficiary transfer) have satisfied the uploads and attestation gates.

The payload identifies no files, tests, or entry points; start by locating the ToD uploads, transmission, beneficiary-transfer, filing-submission, staff-review, email, and PDF flows in the JavaScript/Vue application and its Flask/Postgres services. Done means the stated checklist, attestation gates, guidance, rejection capture, records handling, help content, and contact details work across the required paths.

Written by the indexing model from the issue text.