Trigger vault recovery flow when the user has partial state

### What is this about?

When the user's persisted state is missing one field (i.e. they have only `data` or `meta`, not both), we should treat this as indicative of corruption and trigger the vault recovery flow, even when there is no backup.

Currently we do identify cases like this, but we don't throw the persistence error that triggers the recovery flow unless a backup exists. The flow is also triggered by certain errors being thrown directly by the storage API. But this case of a missing top-level field just results in a background error.

Given that the presence of one field without the other clearly shows that this is not a new installation, we know enough to treat such cases as corruption.

### Scenario

_No response_

### Design

_No response_

### Technical Details

_No response_

### Threat Modeling Framework

_No response_

### Acceptance Criteria

_No response_

### Stakeholder review needed before the work gets merged

- [x] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

### References

_No response_

Start by tracing persisted-state validation for the top-level data and meta fields, along with the storage API errors that invoke vault recovery. Verify that a partial-state case without a backup emits the persistence error and add or update automation coverage for that scenario.

Written by the indexing model from the issue text.