Study history page: update invalid consent text

Nobody has claimed this yet.

## Summary

On the participant-facing study history page, families can see whether the consent videos from their previous sessions have been approved, rejected, or are still pending. When a video has been rejected, the message currently is:

> Consent status: Invalid. There was a technical problem with your consent video, or it did not show you reading the consent statement out loud. Your other data from this session will not be viewed or used by the study researchers.

We should consider the family experience when they have completed a study and the consent has been rejected, but there was nothing obviously wrong with the consent video. This "invalid" message can be confusing to families who have a seemingly-valid consent video, because it fails to capture other reasons why their consent might have been rejected, e.g.
- The researcher determined that they were not eligible (e.g. child not present or clearly out of age range, using a mobile phone/tablet)
- The researcher approved the consent but then realized that there was something wrong with the data, and changed the consent status to "rejected" so that they no longer have access to data that they do not plan to use.

Another thing to keep in mind is that, for the "not eligible" case, there are a number of reasons why the family might've done the study:
- Bad faith: ignored or did not read the eligibility criteria that was clearly stated, hoping to get compensated but probably not surprised if they are rejected
- Good faith: missed the eligibility criteria that would exclude them and are expecting to be compensated
- For fun: they know they are ineligible and simply wanted to do the study anyway - not expecting compensation

Ideally we would have language that is appropriate for all cases.

## Proposed solutions

Here are a number of different possible solutions. These are not all mutually exclusive.

1. Modify the "invalid" statement to include ineligibility:

> There was a technical problem with your consent video, it did not show you reading the consent statement out loud, or **the researcher determined that you did not meet the eligibility criteria**. Your other data from this session will not be viewed or used by the study researchers

2. Change the "Invalid" consent status name to something a little nicer and more general, e.g. "Data not used". (This might also mean changing the "Consent status" label to "Session status" or just "Status").

3. Keep the "Invalid" consent status label/text, but only use it for videos that are actually invalid for the reasons stated, and create a new status label for "Data not used"/"Ineligible".

4. On the consent manager page, add an easy way for researchers to communicate consent video issues to families. E.g. a feedback textbox or checkboxes for common issues. This info would then show up on the study history page so that families can see why a given consent video was rejected.

## Questions

For this case:

> The researcher approved the consent but then realized that there was something wrong with the data, and changed the consent status to "rejected" so that they no longer have access to data that they do not plan to use.

Is this a workflow that we want researchers to use? On the one hand, it is stricter in terms of data access, which is good. But on the other hand, it changes the meaning of "consent judgment" to be something broader.

If we don't want researchers to do this, then maybe we should explicitly suggest an alternative workflow. E.g.
1. Accept all valid consent statements
2. If you determine that the session was ineligible or cannot be used for some other reason (e.g. technical problem), leave the consent status as accepted but let families know via a message or the "feedback" option on their response.

No files, tests, or entry points are named. Start by locating the participant-facing study history consent-status text, then resolve with maintainers which rejection workflow and wording should be supported. Done means the approved status model and family-facing message are implemented with appropriate coverage.

Written by the indexing model from the issue text.